![Информационный блог [Bloginfo]](https://bloginfo.biz/wp-content/uploads/bloginfo.png)
Совсем недавно состоялись ребрендинг и крупное обновление одного из самых успешных и мощных плагинов для защиты WordPress-сайтов. И, несмотря на предупреждения разработчиков, данный апдейт прошел без сучка и задоринки (по крайней мере, у большинства пользователей). Даже не потребовалось проводить ручную реактивацию плагина, о необходимости которой нас предупреждали ранее.
Подробно о смене названия и о том, чего нам ожидать от iThemes Security в будущем, я уже писал в предыдущей статье. Сейчас же я хочу представить вам инструкцию по детальной его настройке. Особенно полезно данное руководство будет тем пользователям, кто не очень хорошо понимает технический английский (плагин пока еще не переведен на русский язык даже частично, как это было ранее) и некоторые специфические технологии.
Содержание:
- Возможности плагина iThemes Security (ex-Better WP Security)
- Установка и настройка плагина iThemes Security (ex-Better WP Security)
- [Global Settings] Глобальные настройки
- [404 Detection] Обнаружение ошибок с кодом 404
- [Away Mode] Режим отсутствия / Гостевой режим
- [Banned Users] Заблокированные пользователи
- [Brute Force Protection] Защита от брутфорс атак
- [Database Backup] Резервные копии (бэкапы) базы данных
- [File Change Detection] Обнаружение изменений файлов
- [Hide Login Area] Скрытие страницы входа в админку сайта
- [Secure Socket Layers] Шифрование (SSL)
- [Strong Passwords] Надежные пароли
- [System Tweaks] Тонкая настройка (твики) системы
- [WordPress Tweaks] Твики WordPress
- [Advanced] Продвинутые (расширенные) настройки
Как всегда в своих статьях, прежде чем перейти к процедуре "нажми туда, нажми сюда", предлагаю ознакомиться с теоретической частью. А точнее с тем, что умеет делать и какие новые функции приобрел iThemes Security. Те, кто уже знаком с данным плагином давно, или те, кому все это не интересно, могут сразу перейти ко второй части инструкции.
Возможности плагина iThemes Security (ex-Better WP Security)
Все знают, что главная задача iThemes Security – это защита блогов на WordPress от всевозможных атак. И защита эта, надо сказать, очень качественная и мощная. На данный момент плагин имеет в своем арсенале более 30 способов обеспечения безопасности. А его разработчики не стесняясь называют свое детище "№ 1" среди подобных плагинов.
Да, сразу же хочу указать на одну важную деталь – безопасность чего бы то ни был, никогда не достигается каким-то одним инструментом. Безопасность – это всегда целый комплекс мер. Следует понимать, что только лишь установка iThemes Security (или любого другого схожего плагина) не может гарантировать вам стопроцентную защиту сайта. Поэтому нужно всегда помнить о базовых принципах защиты – соблюдение интернет-гигиены, содержание в чистоте и превентивная защита компьютера от вредоносного ПО и т.д. и т.п. Также не стоит забывать и о человеческом факторе.
Основной функционал iThemes Security можно поделить на несколько блоков.
Скрытие и удаление (obscure) всего того, что может нести в себе потенциальную опасность
- Смена URL страницы входа в админку - очень полезная функция, и в чем-то даже уникальная (вообще в iThemes Security, как и в раннем Better WP Security, очень много уникальных функций).
- Away Mode – полная блокировка админки в заданное время.
- Удаление заголовков Windows Live Write и RSD.
- Запрет уведомлений об обновлении WP, тем и плагинов.
- Смена логина "admin", если он используется.
- Смена дефолтного ID (1) администратора и префикса (wp_) таблиц БД
- Смена директории wp-content.
- Скрытие вывода ошибок при неверном вводе логина/пароля.
- Отображение для не-админов случайных версий плагинов, тем, ядра.
Защита (protect) WordPress сайта
Сокрытие некоторых частей сайта является очень полезным функционалом, но оно не может предотвратить все атаки. Поэтому среди возможностей iThemes Security имеются, конечно же, и методы защиты - блокировка "плохих" пользователей, повышение безопасности паролей и проч.:
- Сканирование сайта и мгновенное уведомление о слабых местах, имеющих уязвимости, и такое же быстрое их устранение.
- Блокировка проблемных User Agent, ботов и т.п.
- Защита от перебора паролей (brute force) путем блокировки пользователей и хостов, после множественных неудачных попыток входа в админку.
- Общее повышение безопасности веб-сервера.
- Принудительное обеспечение пользователей надежными паролями.
- Шифрование (SSL) админки и любых других страниц и записей (нужен сертификат SSL и поддержка сервером).
- Запрет на редактирование файлов движка, тем и плагинов из адинки.
- Обнаружение и блокировка различных атак на файловую систему и БД сайта.
Обнаружение (detect)
- Мониторинг файловой системы от несанкционированных изменений.
- Обнаружение различных "пауков" и "ботов", которые сканируют сайт в поиске уязвимостей.
- Уведомления по e-mail о случаях блокировки пользователей и хостов.
Восстановление (recovery)
iThemes Security делает регулярные резервные копии базы данных WordPress (по расписанию), что позволяет быстро вернуть исходное состояние сайта в случае его компрометации. К сожалению, базовая версия плагина не поддерживает полный файловый бэкап. Но эта функция имеется в платном сервисе компании iThemes – BackupBuddy.
Другие преимущества
- Возможность создать простую для запоминания страницу входа в админку (можно задать любой адрес, который будет легок для запоминания именно вам).
- Обнаружение ошибок 404, что является важным не только в плане безопасности, но и в плане SEO (битые ссылки на картинки, несуществующие страницы внутри сайта и т.п.)
- Удаление текущей используемой версии jQuery и замена ее на актуальную и безопасную (которая поставляется по умолчанию с WordPress).
Новые функции iThemes Security
- Запрет на выполнение PHP в папке загрузок (uploads).
- Предотвращение создания идентичного логину имени пользователя (отображаемого имени на сайте).
- Скрытие архивов авторов, у которых нет ни единой записи.
- Расширенные возможности по отправке уведомлений
- и др.
Что ж, вот такой вот функционал на данный момент имеется у плагина iThemes Security. Вряд ли у него найдутся серьезные конкуренты. Единственный, на мой взгляд, ближайший конкурент – это плагин BulletProof Security (BPS). Только он более "капризный" к конфигурации веб-сервера, и предназначен, скорее, для продвинутых пользователей.
Итак, с возможностями плагина разобрались, теперь пора приступить к его настройке.
Установка и настройка плагина iThemes Security (ex-Better WP Security)
Установка для новых пользователей происходит в обычном режиме. Кому как удобней (о различных способах установки плагинов WP можете прочитать здесь). Страница плагина в репозитории WordPress.org пока что осталась прежней - https://wordpress.org/plugins/better-wp-security/. Не знаю, изменится ли она в будущем.
При поиске из админки, плагин доступен по названию iThemes Security (formerly Better WP Security), так что на данный момент его можно найти и по новому имени, и по старому. Как долго будет этот вариант названия, я тоже не знаю.
Итак, находим его, устанавливаем, активируем. И первым делом видим такую картину:
Нас интересует кнопка "Secure Your Site Now" (обезопасьте свой сайт сейчас). Жмем на нее, и нас встречает окно первичных настроек "Important First Steps" (важные первые шаги):
Все эти базовые настройки можно пропустить, и произвести их позже вручную. Для этого в нижнем правом углу есть ссылка "Dismiss" (отклонить). Но я рекомендую произвести их именно сейчас, в автоматическом режиме.
Итак, мы видим 4 кнопки:
- Back up your site – сделайте резервную копию БД сайта. Рекомендуется сделать это еще раз (хотя перед установкой плагина вы уже должны были сделать бэкап самостоятельно). Данная копия будет создана и отправлена на ваш административный e-mail средствами самого плагина.
- Allow File Updates – разрешить обновление файлов. Речь идет о редактировании файлов wp-config.php и .htaccess, которое требуется для корректной работы плагина. Данная кнопка позволяет ему сделать автоматическое безопасное обновление этих файлов.
- Secure Your Site – обезопасьте свой сайт. Воспользуйтесь кнопкой One-Click Secure (безопасность в один клик), чтобы плагин активировал настройки по умолчанию. Причем будут активированы только те функции, которые не должны вызывать конфликтов с другими плагинами. Всё остальное можно будет настроить позже.
- Help Us Improve – помогите нам стать лучше. Эта кнопка активирует функцию анонимного сбора данных об особенностях вашего сайта (вероятно - версия WP, установленные плагины, возникшие конфликты и т.п.) в целях улучшения плагина в будущем. Еще раз сделаю акцент на том, что сбор статистики анонимен, и компания iThemes не идентифицирует по ней пользователей. Решайте сами, включать эту опцию или нет.
В общем, жмите поочередно, как минимум на три кнопки из четырех (вместо каждой из них появятся уведомления об успешном действии). Затем жмите на "Dismiss", чтобы закрыть это окно.
Теперь необходимо настроить наш iThemes Security более тщательно.
Все настройки плагина находятся в панели управления (Dashboard):
Сверху, как вы видите, находятся вкладки, по которым осуществляется основная навигация по настройкам. На главной же вкладке - Dashboard - имеется несколько блоков. Для удобства, их можно сворачивать. Также можно менять их местами. Вообще, здесь находится различная обзорная информация и уведомления. А в правой части - рекламные предложения от iThemes.
Сразу скажу, что настраивать iThemes Security мы будем не через кнопки "Fix It", а на следующей вкладке. Но все равно, давайте пробежимся и посмотрим, что тут у нас есть:
[Getting Started] Приступая к работе
Здесь находится короткое видео по настройке, а также ссылка на сайт разработчиков, где можно получить помощь или приобрести PRO-версию плагина (а также другие продукты и услуги). Их видео мы смотреть не будем (моя статья вам на кой? =)), тем более, оно на английском. Так что, сворачиваем эту вкладку, чтобы она нам сейчас не мешала, и, перетаскиваем ее в самый низ (если хотите).
Если у вас есть желание и потребность посмотреть русскоязычное видео по обновлению и настройке iThemes Security, зайдите на сайт к Дмитрию по указанной ссылке. Он очень оперативно выпустил актуальную видеоинструкцию, за что ему большой респект от многих блогеров Рунета! (А с меня ссылка в знак искреннего уважения)
[Security Status] Статус безопасности
Это, пожалуй, самый важный блок на данной странице. Остановимся на нем подробней.
В данном блоке тоже имеются вкладки, которые указывают на степень критичности уведомлений – High (высокая), Medium (средняя), Low (низкая). Также есть две вкладки – All (всё на одной странице) и Complete (готовое, т.е. то, что плагин уже сделал/исправил).
Высокий приоритет (High Priority) - отмечается бледнорозовым цветом и подразумевает необходимость немедленного исправления.
В моем случае, как вы видите, всего одно замечание – это необходимость настроить резервное копирование БД по расписанию.
Что ж, давайте воспользуемся волшебной кнопкой "Fix it" ("пофиксить", исправить).
Нас тут же перебрасывает на вторую вкладку с основными настройками (Settings), в раздел настроек резервных копий. И указывается тот пункт, который нужно пофиксить. В моем случае – это Schedule Database Backups (расписание для резервирования БД). Отмечаем чекбокс (1), указываем интервал (2) и сохраняем изменения кнопкой Save Changes (3).
Раньше расписание можно было настроить так, чтобы резервные копии делались хоть каждый час. Сейчас же минимальный интервал – это 1 день.
После переходим обратно на вкладку Dashboard и видим, что замечаний с высокой критичностью больше нет.
Можно таким же способом пройтись и дальше - по пунктам Medium Priority и Low Priority, и также воспользоваться кнопками Fix it. Но, мы воспользуемся другим методом - будем производить настройку вручную, на вкладке Settings. Если же вам удобней делать это именно отсюда (с Dashboard), то без проблем. Особой разницы нет. Просто на основной странице плагина у всех могут быть разные уведомления. Поэтому я буду настраивать iThemes Security непосредственно через настройки (да и вообще, так удобней и правильней, как мне кажется)
Но перед этим мы быстро пробежимся по остальным информационным блокам Dashboard.
[Active Lockouts] Активные блокировки
Здесь плагин будет информировать нас о том, какие узлы (т.е. IP-адреса ботов или живых людей) или пользователи (те, кто зарегистрирован на сайте) были заблокированы за различные недопустимые действия.
[System Information] Системная информация
Тут находится информация об активном пользователе (т.е. о вас) - ваш IP-адрес и User Agent. Также здесь указываются:
- Абсолютный адрес сайта и корневая папка на сервере
- Доступны ли на запись файлы .htaccess и wp-config.php
- Информация о БД, сервере и PHP
- Некоторые параметры WordPress
- Используемый билд iThemes Security (версия сборки, которую нужно будет указать при обращении в саппорт; версия билда отличается от той версии, что указывается на странице плагина – это немного разные вещи)
[Rewrite Rules] Перезаписанные правила
Здесь будет находиться информация о том, какие именно правила прописал плагин в файл .htaccess
[wp-config.php Rules] Правила для wp-config.php
Аналогично предыдущему пункту, только уже для другого файла, как вы понимаете.
Я для себя лично немного поменял местами эти блоки и все их свернул. Таким образом, главная страница панели управления плагином у меня теперь выглядит более компактно, да и открывается быстрее:
В общем, рекомендую с вкладкой Dashboard на время покончить, и перейти к самому главному - непосредственно к настройкам (Settings).
Все настройки плагина скомпонованы по отдельным блокам (секциям). Для удобства их также можно сворачивать или менять местами. Здесь же имеется и выпадающее меню для быстрой навигации по разделам. Также это меню будет всегда сопровождать вас в правой части области просмотра, в виде плавающего блока с выпадающем списком.
Напомню сразу, что после внесения изменений в любой из секций, необходимо сохраняться ("Save Changes")
[Global Settings] Глобальные настройки
Первым пунктом здесь значится Write to Files - запись в файлы. Этот пункт уже отмечен, и "галочку" снимать ни в коем случае не нужно (!). Иначе вы запретите плагину запись в файлы .htaccess и wp-config.php, тем самым все созданные правила и параметры конфигурации придется прописывать вручную.
Следующие два пункта – это указание e-mail адресов для получения уведомлений (Notification Email) и бэкапов (Backup Delivery Email). Причем адреса можно указать разные; можно добавить и несколько адресов. Каждый e-mail следует прописывать с новой строки.
В поле "Host Lockout Message" можно указать сообщение, которое будет выводиться тем, кто был заблокирован плагином. По умолчанию лаконично указано "error". Можете проявить креативность и написать что-нибудь оригинальное. Но смысла в этом нет, т.к. в основном будут блокироваться всяческие боты.
В поле "User Lockout Message" можно прописать сообщение, которое будет отображаться для тех зарегистрированных на сайте пользователей, чей аккаунт будет заблокирован за неудачные попытки залогиниться. Можно оставить дефолтное сообщение "You have been locked out due to too many login attempts" ("Вы были заблокированы из-за слишком большого количества попыток входа").
Blacklist Repeat Offender – это черный список "рецидивистов", т.е. тех, кто регулярно пытается подобрать пароль или производит иные запрещенные действия. По умолчанию функция активирована, и я не рекомендую ее отключать.
Дальше идет указание как, за что, кого и на сколько блокировать:
Blacklist Threshold – порог для внесения IP-адреса в блэклист. То есть, здесь указывается то количество блокировок пользователя или хоста, после которого IP-адрес нарушителя будет перманентно добавлен в черный список. Дефолтное значение = 3. Это значит, что если кто-то получил три блокировки за попытки подобрать пароль к админке, то он отправляется в блэклист.
Blacklist Lookback Period – период, на который нарушитель отправляется в бан. Здесь указывается кол-во дней, которое нарушитель будет находиться в черном списке. Это значение можно увеличить (по умолчанию стоит 7 дней).
Lockout Period – период блокировки. Продолжительность времени (в минутах), в течение которого, хост или пользователь будет заблокирован после первичных нарушений (без внесения в черный список).
Пример: допустим, кто-то пытается подобрать пароль к админке, делает несколько неудачных попыток и временно блокируется на указанное кол-во минут. Если после разблокировки он не прекращает свою атаку, и получает еще две (если в Blacklist Threshold указано значение 3) временные блокировки, тогда он отправляется непосредственно в черный список.
Lockout White List – белый список. Здесь можно указать IP-адреса, которые не будут вноситься в блэклист. Если у вас статический айпишник, то целесообразно прописать его в данное поле, чтобы не возникало никаких потенциальных трудностей с доступом (прописаться в белом списке можно и с динамическим IP-адресом).
Следует отметить, что если вы активировали режим Away Mode (о нем позже), то в указанное в нем время, вы все равно не сможете попасть в админку. Правила Away Mode приоритетней белого списка.
IP-адреса в White List прописываются в стандартном IPv4 формате – например, 123.123.123.123. Также допускается использование символа (*) для указания диапазона адресов. Например, запись вида 123.123.123.* будет означать, что все IP-адреса, начиная с 123.123.123.0 и заканчивая 123.123.123.255, будут разрешенными. Это удобно, если у вас нет статического айпишника.
Каждый IP-адрес или подсеть следует вносить с новой строки.
Email Lockout Notifications – отправка писем, на указанную в поле Notification Email электронную почту, всякий раз, когда какой-либо хост или пользователь сайта будет заблокирован.
Log Type – тип логирования. Здесь можно указать, какие именно журналы будет вести плагин iThemes Security. Варианта три – только БД (Database Only), только файловые логи (File Only) или оба вида (Both).
Каждый из этих вариантов записи событий имеет свои преимущества и недостатки.
- Database Only – в журнал будут записываться все изменения, вносимые в БД, такие, как новый пост, новый комментарий и т.п. Также логироваться будет создание бэкапов. Зачем это нужно рядовому пользователю, я не понимаю. Советую не использовать данный режим.
- File Only – более полезный вариант логирования. Будут записываться разного рода ошибки 404, изменения файлов (при активной опции) и т.п. Рекомендую использовать именно этот режим.
Имейте в виду, что любая запись на диск сервера (а логирование – это, естественно, запись) вызывает дополнительную нагрузку. Ну, и сами логи занимают место, конечно же. Странно, что в плагине нет возможности полностью отключить журналирование
Days to Keep Database Logs – сколько дней хранить журналы БД. Если вы не активировали режим логирования Database Only, то нет никакой разницы, какое кол-во дней указывать в этом поле. Потому что файловый журнал будет все равно храниться неограниченное время, но с одним важным условием – по достижении размера в 10 MB, файл будет перезаписываться. Хорошее нововведение, потому как раньше, у некоторых пользователей логи съедали огромное кол-во дискового пространства, и их (логи) необходимо было чистить с завидной регулярностью. Вручную.
Path to Log Files – путь к файлам логов. Тут все понятно. Есть только одно замечание – указанная директория должна быть доступна для записи, и одна рекомендация – в целях безопасности не следует хранить логи в корне сайта. Короче говоря, оставляем все, как есть.
Allow Data Tracking – разрешить сбор статистики для iThemes. Это то самое, о чем мы уже говорили ранее. Хотите - включайте, хотите - нет. Еще раз напомню, что данные собираются и отправляются анонимно и пойдут они на пользу в развитии плагина.
Что ж, с Global Settings разобрались. Идем дальше. Ох, как много мне еще писать, а вам читать =)
[404 Detection] Обнаружение ошибок с кодом 404
Данная функция заключается в сборе информации о том, каким хостам многократно отдается ошибка 404, и в их блокировке соответствующим образом. Этот анализ важен по нескольким причинам, главная из которых – предотвратить сканирование на предмет имеющихся уязвимостей.
Также данная опция дает дополнительное преимущество, помогая вам найти скрытые проблемы, вызывающие ошибки 404. Это могут быть, например, какие-то "битые" картинки или нерабочие внутренние ссылки. Все ошибки будут регистрироваться, а посмотреть их можно на вкладке "Просмотр журналов" (Логи, Logs).
Первым делом в этой секции мы видим некоторую информацию о текущих настройках по блокировкам (все это мы настраивали в блоке глобальных настроек). У меня, например, это выглядит вот так:
Дальше следуют настройки конкретных значений.
Enable 404 detection – собственно, активация данной функции.
Minutes to Remember 404 Error (Check Period) – количество минут (контрольный период), в течение которого будут засчитываться локауты. Дефолтное значение 5 минут.
Пример: какой-то бот/парсер "долбит" сайт в поиске различных уязвимых файлов и страниц, и, не находя их, получает в ответ ошибки с кодом 404. Делает он это, предположим, в течение минуты, потом останавливается на минуту, и начинает снова. Плагин все эти его действия будет помнить и вскоре тот получит бан.
Если же, допустим, бот "подолбил" 30 секунд и ушел с сайта минут на 10, то при следующем его визите плагин будет считать его уже за вновьприбывшего, а прошлые "заслуги" данного хоста помнить не будет.
Поэтому, дефолтное значение можно немного увеличить (к примеру, до 10 минут).
Error Threshold – порог допустимых ошибок. Кол-во ошибок (в пределах контрольного периода) при достижении которых произойдет блокировка. Если задать значение 0, то запись ошибок будет происходить без блокировок (такой вариант следует использовать только в целях отладки, потому как при нем не будет пресекаться сканирование на уязвимости).
Значение по умолчанию = 20. Не думаю, что стоит его увеличивать, ведь ошибки 404 могут отдаваться не только при подозрительных действиях, но и, например, если у сайта нет favicon, или apple-touch-icon.png и т.д.
И вот тут очень кстати в iThemes Security появилось хорошее нововведение – список исключений (white list) для ошибок 404. В него уже добавлены наиболее известные общие файлы, отсутствие которых вызывает данные ошибки:
Этот список можно дополнять и другими известными файлами. Но более правильным решением будет привести все в порядок – создать фавикон, apple-touch-icon.png, robots.txt, sitemap.xml и т.п. Ведь white list не предотвращает запись ошибок сервером. А, как вы уже знаете, любая запись на жесткий диск – это дополнительные нагрузки.
[Away Mode] Режим отсутствия / Гостевой режим
Данный режим позволяет полностью отключить доступ к админпанели WordPress в заданные дни или часы. Это может быть весьма полезным, и уж точно не будет лишним в плане дополнительной защиты.
Как это работает? Допустим, вы никогда не заходите в админку ночью и ранним утром. Или, скажем, вы уезжаете в отпуск, и точно знаете, что в это время не будете пользоваться админкой. Почему бы тогда ее вообще не отключить на эти часы или дни? Правильно? Правильно.
Прежде чем активировать и настроить данную опцию, помните, что часовой пояс, используемый на сайте, может отличаться от вашего реального часового пояса. Так что, производите настройки Away Mode, основываясь на глобальных настройках самого сайта.
Итак, чтобы включить гостевой режим, отмечаем чекбокс "Enable away mode".
Далее следует "Type of Restriction" – тип ограничения: ежедневный (Daily) или единоразовый (One Time).
Если выбрать Daily, то для указания временного интервала нам будут доступны два параметра - Start Time (стартовое время) и End Time (конечное). Время указывается в 12-часовом формате. AM – до полудня; PM – после полудня.
Пример: если я хочу заблокировать админку в период с 2-х ночи до 7 утра, то я указываю - от 2:00 AM до 7:00 AM. В общем, погуглите, если необходимо. В интернете есть сервисы и таблицы соответствия 24- и 12-часовых форматов.
Если выбрать режим единоразовой блокировки, то нужно указывать дату и время ее начала, и дату и время ее окончания. Все гениальное - просто.
[Banned Users] Заблокированные пользователи
Эта функция позволяет полностью запретить доступ к сайту определенным хостам и User Agent, что благоприятно скажется на противодействии спамерам, парсерам и прочим нечистоплотным людям и ботам.
Первым делом нам предлагается подключить базовый черный список известных проблемных User Agent, созданный группой HackRepair.com.
Вообще, что такое User Agent? В нашем случае - это некая информация, по которой (помимо прочего) веб-сервер идентифицирует обратившийся к нему хост. В ней содержится используемый браузер, ОС и проч. У поисковых роботов имеются свои собственные юзер-агенты, у спамерских ботов и различных парсеров свои и т.д. И на основании известных нежелательных User Agent используются подобные Black-листы.
Итак, чтобы активировать базовый блэклист отмечаем параметр "Enable HackRepair.com's blacklist feature". Если вам нужен самый свежий и полный список "плохих" юзер-агентов и хостов, то его всегда можно взять на странице http://pastebin.com/5Hw9KZnW и самостоятельно добавить в файл .htaccess
Есть одно замечание! Недавно где-то видел инфу, что данную опцию лучше не активировать, т.к. это может повлечь за собой блокировку некоторых поисковых роботов. Лично у меня всегда был подключен этот блэклист и я не наблюдал ни в Я.Вебмастере, ни в Гугл Вебмастере каких-либо проблем с доступом этих пауков к сайту. Так что, рекомендую эту функцию активировать. Кроме того, можно проанализировать данный список и убедиться, что в нем не присутствуют идентификаторы ни Гугла, ни Яндекса.
Помимо дефолтного блэклиста существует возможность и ручной блокировки определенных хостов или UA. Для этого необходимо активировать опцию "Enable ban users", после чего нам станут доступны три поля для ввода:
- Ban Hosts – блокировка хостов. Сюда всегда можно внести какие-либо IP-адреса, с которых регулярно идут атаки на ваш сайт или спам.
- Ban User Agents – блокировка UA. В большинстве случаев, пополнять этот список вручную нет необходимости, достаточно базового списка с HackRepair.com. Но если вы вдруг обнаружите постоянную атаку с определенных UA, то почему бы и не воспользоваться возможностью их блокировки.
- Whitelist Users – белый список. Можете внести свой IP-адрес.
IP-адреса в эти списки вносятся по такому же принципу, как и в Lockout White List.
[Brute Force Protection] Защита от брутфорс атак
Очень важная функция, которая является дополнительным щитом поверх смены URL админки. А если вы не станете использовать подмену страницы входа в админ-панель (об этом чуть позже), то данная функция становится не просто важной, а архиважнейшей. Более того, она позволяет отказаться от дополнительных плагинов, выполняющих ту же самую задачу (Limit Login Attempts, Login Lockdown и др.).
По умолчанию опция уже активирована. А если по какой-то причине "галочка" возле "Enable brute force protection" не установлена, то поставьте ее.
Параметр "Max Login Attempts Per Host" отвечает за максимальное кол-во попыток для одного хоста. Дефолтное значение = 5. Т.е., если кто-то 5 раз подряд неправильно введет логин или пароль, то он будет заблокирован на указанное время.
"Max Login Attempts Per User" отвечает за количество попыток для конкретного пользователя. Т.е., если кто-то вбивает свой логин (или злоумышленник знает существующие на сайте логины), но неверно указывает пароль, то в бан уходит именно этот пользователь (его учетная запись). Значение по умолчанию – 10 попыток.
И заключительный параметр в этом блоке настроек – "Minutes to Remember Bad Login (check period)" – контрольный период, в течение которого плагин будет помнить неудачные попытки залогиниться. Также оставляем 5 минут. При желании, можно увеличить это значение.
[Database Backup] Резервные копии (бэкапы) базы данных
Доподлинно известно, что одним из лучших способов защиты и устранения последствий атак являются резервные копии. Каждый блогер или владелец сайта просто обязан иметь ежедневные бэкапы БД.
В большинстве случаев, блогеры перекладывают эту задачу на хостинг. Но, как говорится, Aide toi et le ciel t’aidera. Так что, помимо хостерских бэкапов всегда следует иметь и запасной вариант. Кто-то использует для этого специальные плагины и скрипты, но зачем? Ведь iThemes Security справляется с этой задачей на 5+
Итак, первым параметром здесь является "Backup Full Database" – это режим создания полной резервной копии таблиц сайта. Если активировать данную опцию, то в бэкапы будут добавляться абсолютно все таблицы, которые могут и не относиться непосредственно к сайту (например, какие-то сторонние скрипты и т.п.). На всякий пожарный рекомендую ею воспользоваться, хотя это, в общем-то, и не критично.
Далее следует выбор способа резервного копирования - Backup Method. Подразумевается три варианта:
- Save Locally and Email – хранить бэкапы на сервере и отправлять их по e-mail
- Email Only – отправлять только по электронной почте
- Save Locally Only – хранить только на сервере
Рекомендую использовать исключительно Email Only (если ваша БД не очень больших размеров). Потому что хранить резервные копии на том же сервере, где расположен сам сайт – это а) бессмысленно; б) трата дискового пространства.
Если же вы решили хранить бэкапы (и) на сервере, то в поле "Backup Location" можете указать директорию для их хранения (или оставить путь по умолчанию). Ни в коем случае не рекомендуется указывать корневую папку сайта для этих целей.
Убедитесь, что у вас отмечен пункт "Compress Backup Files" – это сжатие файлов резервных копий. Таким образом, файл БД будет упакован в ZIP-архив, что значительно уменьшит его размер.
Далее следует указание некоторых специфических таблиц, которые можно исключить из бэкапов (Exclude Tables). К ним относятся таблицы, создаваемые некоторыми плагинами, и которые не всегда представляют какую-то реальную ценность.
По умолчанию в поле "Excluded Tables" включены таблицы, создаваемые плагином iThemes Security, а в левом поле "Tables for Backup" – те таблицы, которые создаются различными плагинами (в основном – это разные логи), но не относящиеся (как правило) непосредственно к содержимому сайта.
Если вы уверены, что какие-то таблицы из правого поля не несут пользы для резервирования БД, то можете их исключить из создаваемых бэкапов. Тем самым может значительно уменьшиться размер резервных копий. Если не уверены, то оставляйте все как есть.
В любом случае помните, что данные бэкапы могут отличаться от бэкапов, созданных хостером, потому как на хостинге создаются полные резервные копии БД. Но, это ни в коем случае не означает, что резервные копии, созданные в iThemes Security, будут недееспособны. Отнюдь.
Ну, а далее идет расписание - Schedule Database Backups. О нем мы уже говорили почти в самом начале. Рекомендую ставить минимально возможное значение - 1 день. Таким образом, на вашу почту ежедневно будет приходить бэкап БД сайта.
[File Change Detection] Обнаружение изменений файлов
Даже самые лучшие решения в области безопасности могут потерпеть неудачу. Как в таком случае узнать, что кто-то получил административный доступ к вашему сайту? Скорее всего, злоумышленник будет менять какие-то файлы, внося в них свой код. Отслеживанием таких изменений и занимается данная функция.
В отличие от других решений, iThemes Security сравнивает файлы локально, с момента последней проверки, а не сверяет их с "заводскими" файлами удаленно.
После каждой проверки вы будете знать, были ли внесены какие-то изменения лично вами, или они появились в результате компрометации. Обращайте внимание, главным образом, на различные системные файлы, которые вдруг изменились без видимой причины (не было никаких обновлений, вы лично не вносили в них изменения и т.п.).
Если так случится, что на вашем сайте вдруг обнаружится вредоносный код, то благодаря данной опции вам проще будет отследить когда и куда он мог быть добавлен.
Нажмите кнопку "File Scan Now", чтобы произвести добавление файлов и первичное сканирование. Если изменения обнаружатся, то вас перебросит на страницу журналов ("Logs") для просмотра деталей. Журналы изменений файлов находятся в секции "File Change History":
Возвращаемся обратно к настройкам. Чтобы активировать ежедневную автоматическую проверку изменения файлов, отметьте галочкой пункт "Enable File Change detection".
Следующим параметром - "Split File Scanning" - можно активировать режим разделения сканируемых файлов на категории. Всего категорий 7. Это плагины, темы, wp-admin, wp-includes, uploads (загрузки), wp-content и последняя – это все то, что не вписывается в предыдущие категории. Проверка этих частей будет разделена равномерно, в течение дня. Из чего следует, что данная настройка приводит к увеличению числа уведомлений, но в то же время она снижает нагрузку на сервер, что особенно актуально на "слабом" хостинге.
А вот дальше идет очень интересная функция, которой не было в ранних версиях плагина – это "Include/Exclude Files and Folders", т.е. включение/исключение файлов и папок.
Почему это так важно? Раньше, при включенном отслеживании изменений файлов, сыпалось столько уведомлений, что многие просто отключали эту опцию. Связано это было, в том числе и с тем, что при использовании плагинов кэширования файлы на хостинге меняются весьма часто и в большом кол-ве (кэш). Сейчас же подобные кэшированные файлы можно исключить из проверки.
Делается это так (на примере папки с кэшем, которую использует плагин Hyper Cache, другие подобные плагины, скорее всего, используют эту же папку):
Имеется также возможность не исключать определенные файлы и папки, а наоборот включать только выбранные. Для этого в выпадающем меню выберите "Include Selected", и укажите, какие именно файлы и папки вы хотите мониторить.
В поле "Ignore File Types" можно указать различные расширения файлов, которые будут игнорироваться функцией отслеживания изменений. Обычно это файлы картинок и т.п. То есть это НЕ должны быть текстовые файлы (включая php, js и проч.), т.к. именно в них обычно и внедряется вредоносный или иной посторонний код.
Параметр "Email File Change Notifications" отвечает за отправку уведомлений об изменениях на указанный(ые) в глобальных настройках e-mail(ы).
Функцией "Display file change admin warning" можно включить/отключить показ уведомлений в админке.
Имеется возможность выбрать оба режима или какой-то один. Если же отключить их оба, то вы вообще не будете получать никаких уведомлений, но изменения в любом случае можно будет просматривать на вкладке "Logs".
[Hide Login Area] Скрытие страницы входа в админку сайта
Еще одна уникальная функция плагина iThemes Security, благодаря которой можно здорово обезопасить свой сайт от брутфорс атак.
Работает это следующим образом – вместо стандартного URL входа в админку (site.ru/wp-login.php) вы можете указать любую произвольную страницу, например, site.ru/voydi_v_menya. Таким образом, вряд ли кто-то узнает, по какому адресу находится страница входа.
Также данная функция призвана облегчить запоминание адреса бэкенда (так часто называется админка сайта), и отказаться, наконец, от использования виджета META на сайте.
Для включения этого режима поставьте галочку возле "Enable the hide backend feature".
В поле "Login Slug" (можно перевести, как "Вход для ленивых") укажите желаемый адрес для входа в админку. Это может быть любое удобное и запоминающееся для вас слово (или же набор символов). Само собой здесь нельзя использовать "login", "admin", "dashboard", или "wp-login.php". Также не рекомендую применять для адреса страницы входа какие-то ваши ники в интернете, дату рождения и т.п., потому как все это очень легко вычислить.
Если после скрытия админки у вас возникли проблемы с доступом в нее, то возможной причиной может стать несовместимость с темой. Для того, чтобы исправить это, воспользуйтесь опцией "Enable Theme Compatibility".
В поле "Theme Compatibility Slug" указывается адрес, который будет выводиться при попытке зайти в админку по стандартному адресу site.ru/wp-login.php (если активирована предыдущая функция).
Ну что, устали? Потерпите, осталось не очень много =)
[Secure Socket Layers] Шифрование (SSL)
Secure Socket Layers (SSL) - это технология, которая используется для шифрования данных, передаваемых между сервером и посетителями сайта. Если SSL активирован, он делает невозможным перехват данных для злоумышленника (в последнее время идет много споров на этот счет, но все равно технология остается максимально устойчивой). Поэтому рекомендуется использовать шифрование на страницах ввода паролей и иных данных. Любые, более-менее крупные сайты, где используется ввод и передача конфиденциальной информации, используют шифрование (на таких сайтах адрес начинается с https://)
Однако этот режим требует того, чтобы ваш сервер имел поддержку SSL.
Все это актуально для тех сайтов, где предусмотрена регистрация, имеется разного рода "личка", и, конечно же, для интернет-магазинов и т.д. Для обычных сайтов и блогов SSL-сертификат, как правило, не приобретается. Он попросту не нужен, т.к. все статьи, комментарии и все прочее, итак находятся в открытом доступе. Единственное, где шифрование может оказаться полезным для наших блогов – это страница входа и сама админка (этим мы сможем обезопасить себя, например, от перехвата пароля в момент его ввода).
В общем, в 99% случаев все это блогерами не используется, поэтому подробно рассматривать данную секцию мы не станем.
[Strong Passwords] Надежные пароли
В данном разделе можно включить принудительное использование надежных паролей согласно оценке встроенного в WordPress измерителя паролей.
Данная настройка практически не актуальна для однопользовательских сайтов, где доступ в админку есть только у владельца (администратора), и где не предусмотрена регистрация пользователей. Тем более, вы, мои дорогие читатели, наверняка знаете, как выбрать стойкий пароль, и где его хранить (ну, конечно же, в менеджерах паролей, типа KeePass, 1Password и т.п.)
В остальных случаях рекомендуется указать минимальную роль, для которой будет требоваться надежный пароль. Как правило, это Авторы, Редакторы и Администраторы. Для Участников и Подписчиков требовать сложный пароль не имеет смысла.
Но, опять же, все зависит от сайта. Если у вас, скажем, интернет-магазин, то требовать надежные пароли следует от любого пользователя, который будет в нем регистрироваться.
Что ж, нам осталось разобраться с двумя последними очень интересными секциями...
[System Tweaks] Тонкая настройка (твики) системы
Это дополнительные настройки, которые могут быть использованы в целях дальнейшего укрепления безопасности вашего WordPress сайта.
Рекомендую активировать каждую из этих настроек в обязательном порядке (кроме тех пунктов, где имеются оговорки, о чем я сообщу отдельно).
Protect System Files – защита системных файлов. Предотвращение публичного доступа к readme.html, readme.txt, wp-config.php, install.php, wp-includes и .htaccess. Эти файлы могут содержать важную информацию о сайте, и публичный доступ к ним не нужен после успешной установки WordPress.
Disable Directory Browsing - отключение просмотра каталогов. Запрещает пользователям видеть список файлов в директориях, даже при отсутствии в них индексного файла (index.php).
Filter Request Methods – фильтрация методов запроса TRACE, DELETE, TRACK. Я не силен ни в PHP, ни в веб-серверных технологиях, но предполагаю, что речь идет о запросах, которые могут нести какую-либо нежелательную функцию (напр., возможность осуществления XSS-атаки). Если кто расскажет в комментариях об этом более подробно или поправит меня, буду очень признателен (да и не только я).
Filter Suspicious Query Strings in the URL - фильтрация подозрительных строк запроса в URL. Это очень частый признак того, что кто-то пытается получить доступ к вашему сайту. Но, следует иметь в виду, что некоторые плагины и темы также могут быть заблокированы при активации данной опции (обязательно проверьте работоспособность сайта после ее включения!). Будет очень хорошо, если никаких проблем не возникнет, т.к. этот метод защиты очень важен! Если же проблемы все-таки появятся, то лучшим вариантом будет избавиться (по возможности) от несовместимого плагина, чем не активировать данную функцию.
Filter Non-English Characters – фильтрация не англоязычных символов из строки запроса. Этот фильтр работает только в том случае, если активирован предыдущий. Но, если на вашем сайте используется русская адресация (названия статей, рубрик и т.п.), то эту функцию включать не стоит. Иначе сайт может стать недоступным!
Вообще, если вы имеете дело с сайтами, с web, с серверами, линуксами и т.д., то пора уже привыкнуть, что использование не латинских символов в каких-то служебных целях крайне не желательно.
Filter Long URL Strings – фильтрация длинных строк в URL. Ограничивает число символов, которое можно послать в URL (не более 255). Хакеры часто используют длинные URL-адреса для внедрения сторонней информации в БД (SQL-инъекций).
Remove File Writing Permissions – удаление разрешений на запись в файлы. Данная функция запрещает различным скриптам и пользователям запись в файлы wp-config.php и .htaccess. Следует обратить внимание, что в данном случае, как и в случае с другими плагинами, эту защиту можно преодолеть. Но в любом случае, данный запрет укрепляет безопасность указанных файлов.
Если функция активирована, то на эти файлы устанавливаются права 444. В случае отключения, им возвращаются права 644.
Disable PHP in Uploads – запрет на выполнение PHP в папке uploads. Новая функция, которая позволяет предотвратить загрузку вредоносных скриптов в указанную папку.
Итак, мы активировали все (по возможности) эти функции, и переходим к последнему блоку.
[WordPress Tweaks] Твики WordPress
Это дополнительные настройки, которые могут быть использованы в целях дальнейшего укрепления безопасности вашего WordPress сайта. Как и в случае с системными твиками, из-за некоторых из этих настроек могут возникнуть несовместимости и сбои в работе сайта. Рекомендуется включать их также поочередно.
Remove WordPress Generator Meta Tag – удаление мета-тега Generator. Удаляет из заголовка сайта мета-тег <meta name="generator" content="WordPress [version]" />, который указывает используемую на сайте версию WP. Данная функция упразднена с версии 4.9.0.
В любом из мануалов по защите WordPress, первым делом рекомендуется удалять данный мета-тег, т.к. зная версию движка, злоумышленнику проще определить его уязвимости и вектор атак. Когда-то мы проделывали это вручную, теперь же за нас всё делает iThemes Security.
Remove the Windows Live Writer header – удаление заголовка Windows Live Writer. Если вы не пользуетесь WLW или другими платформами для написания и публикации статей на блоге, то данную функцию можно не активировать.
Remove the RSD (Really Simple Discovery) header – удаление заголовка RSD. Если вы не интегрировали свой блог с внешними XML-RPC сервисами, (напр., с Flickr), то функция RSD является для вас в значительной степени бесполезной.
Говоря по-простому, обе предыдущие опции вырезают из header`а сайта примерно такие строки:
<link rel="wlwmanifest" type="application/wlwmanifest+xml" href="/wp-includes/wlwmanifest.xml" /> <link rel="EditURI" type="application/rsd+xml" title="RSD" href="/xmlrpc.php?rsd" />
XML-RPC – это стандарт (протокол), используемый в т.ч. и WordPress для удаленной публикации статей и др. данных из сторонних программ, платформ и сервисов. Если вы не пользуетесь такими функциями (к ним, кстати, относятся и различные WP-клиенты для Android и iOS), то настоятельно рекомендуется отключить данный протокол. Из-за периодического появления в нем новых уязвимостей.
Недавний случай: в середине марта сего года были зафиксированы очередные мощные DDoS-атаки с использованием уязвимости XML-RPC. Но дидосились не сами WordPress-сайты с XML-RPC, они лишь использовались в качестве ретрансляторов для усиления атак (т.е. выступали в качестве участников ботнета).
Я могу ошибаться, но если память мне не изменяет, было обнаружено более 60 тыс. WP-сайтов, которые выступали в роли ботов для DDoS-атак из-за данной уязвимости. А их владельцы даже и не подозревали об этом. Да многие до сих пор, наверное, и не подозревают. Я даже видел ссылку на специальный сервис, где можно проверить свой сайт, не участвует ли он в подобных DDoS-атаках.
Вот поэтому рекомендуется отключать XML-RPC (если, конечно, вы его не используете). Раньше в админке WordPress была специальная функция для его деактивации. Сейчас же ее нет. Поэтому придется чуточку повозиться вручную (в интернете много информации о том, как это сделать) или же воспользоваться функцией iThemes Security, до которой мы скоро дойдем.
Reduce Comment Spam – уменьшение спама в комментариях. Эта опция позволит сократить кол-во спама, блокируя комментарии от ботов, не имеющих реферера или User Agent. Вряд ли это может повлиять на нормальные комментарии, так что включаем, не задумываясь. Облегчим работу антиспам-плагинам.
Display Random Version – отображение случайной версии WordPress там, где невозможно удалить ее показ полностью. Актуально для многопользовательских сайтов.
Disable File Editor – отключение редактора файлов в админке WP. Не пользуетесь внутренним редактором? Смело отключайте.
Disable XML-RPC – отключение XML-RPC. То самое, о чем мы недавно говорили. Если не пользуетесь средствами удаленной публикации, обязательно отключите XML-RPC.
Enqueue a safe version of jQuery – установка безопасной версии jQuery. Эта функция удаляет текущую используемую версию библиотеки jQuery и заменяет ее на безопасную (которая поставляется по умолчанию с WordPress). Если версия этой библиотеки удовлетворяет требованиям iThemes Security, то ничего делать не нужно:
Disable login error messages – отключение сообщений об ошибках, которые отображаются при неудачной попытке входа в систему.
Force Unique Nickname - принудительное использование уникального ника, отличающегося от логина.
Disable Extra User Archives – отключение архивов пользователей, чье кол-во записей равно 0.
Ну, вот и все по основным настройкам. Теперь можно вновь перейти на вкладку Dashboard, и посмотреть на текущие уведомления. В моем случае сейчас они выглядят так:
Осталось пройтись по оставшимся вкладкам.
[Advanced] Продвинутые (расширенные) настройки
Приведенные ниже настройки являются продвинутыми. Убедитесь, что у вас имеется работоспособная резервная копия сайта перед изменением любого параметра на этой странице. Кроме того, эти установки не будут обращены вспять, даже если вы удалите плагин iThemes Security (!).
Тем не менее, все используемые здесь настройки рекомендуются самим сообществом WordPress.org, и они помогут в улучшении безопасности вашего сайта.
Admin User – удаление пользователя admin, если он имеется. Я никогда не использую дефолтный логин "admin" даже на тестовых сайтах. Поэтому здесь у меня никаких опций нет. Имеется лишь надпись "It looks like you have already removed the admin user. No further action is necessary (Похоже, вы уже удалили пользователя admin. Никаких дополнительных действий не требуется)". Надеюсь, что у вас также.
Change Content Directory – смена контент-директории. Ни в коем случае не экспериментируйте с этой функцией! Ее рекомендуется использовать только на вновь создаваемых сайтах. Иначе вы попросту потеряете все содержимое блога (не физически, конечно). И, как уже говорилось, не поможет даже удаление плагина. Хотя вернуть все на круги своя достаточно просто (нужно немного поправить файл wp-config.php).
Вообще, сменить директорию wp-content можно и на уже работающем сайте, но для этого потребуется вносить изменения в БД, в некоторые плагины, файлы движка т.д. Короче, задачка не для нас – рядовых блогеров. А вот если вы планируете создавать новый сайт, то первым делом установите iThemes Security и попробуйте воспользоваться данной возможностью. В будущем обязательно пригодится.
Change Database Prefix – смена префикса БД. По умолчанию в WordPress используется префикс wp_, что может облегчить задачу для злоумышленника. Рекомендуется менять дефолтный префикс таблиц.
Перед процедурой смены префикса обязательно сделайте резервную копию БД!
Ну что ж, теперь точно все =)
Осталось только сказать, что на вкладке Backups можно в любое время создать резервную копию текущего состояния БД (кнопка "Create Database Backup"), а также кратко ознакомиться с сервисом BackupBuddy.
Если что-то осталось не понятным, или у вас есть замечания и дополнения, милости прошу в комментарии.
До новых встреч, друзья. Берегите себя и свои сайты!
С уважением, Александр Майер
Ну нифига себе мануал. Спасибо за работу!! ВОпрос безопастности он конечно актуален всегда, но блин стоолько букф. Очень надеюсь что осилю со второго раза.
Да уж, пришлось "попотеть" немного =) Пытался как-то сокращать, но теряется вся концепция.
Серьезная статья. За один раз не переварить. Вопросы есть. Только теперь нужно перепроверить свои настройки, осмыслить и потом задать.
У меня уже было два обновления плагина. Пока реальная проблема одна, для добавления картинок, деактивирую плагин, добавляю, потом активирую. Иначе идет блокировка сайта. Иду проверять настройки. Спасибо за подробную статью.
На самом деле плагин на вчерашний день имел уже 10 обновлений с момента смены названия. А на сегодняшний день уже 12. Просто было зафиксировано очень много проблем у разных пользователей. Вот они и устраняют их. В будущем так часто он не будет обновляться, я думаю. Кстати, после последнего обновления проблема с картинками не исчезла?
Кстати, благодаря этим и будущим обновлениям часть функций, описанных в статье может стать не актуальной. Например, уже появилась возможность чистить логи вручную (на момент написания статьи этого не было), или - режим совместимости с темами теперь включен по умолчанию. Ну, и т.д.
А насчет вопросов - это всегда пожалуйста. Чем смогу, как говориться. Если проблема с картинками не исчезла, и причину выяснить не удастся, нужно будет сформулировать ее на английском и попросить помощи на форуме поддержки.
Пока проблема с картинками так же актуальна. У Василия было то же самое. Пока потерплю, может что и решится.
Да, я помню, что у Василия такая же проблема. Но терпеть - это не правильно =) Надо искать причину и устранять
У кого возникают блокировки самого себя. На странице http://ithemes.com/security/fixing-ithemes-security-lockouts/ есть инструкция (видимо это возникает очень часто, раз ее написали на сайте). Короче, вот что там пишется:
1. Нужно удостовериться, что блокировка связана с "обнаружения вторжений". Откройте базу данных (через phpMyAdmin) и найти таблицу xxxxxx_itsec_lockouts (где хххххх - ваш префикс таблиц). В этой таблице найдите свой IP-адрес (айпишники находятся в столбце lockout_host). Если IP входит в эту таблицу, то причина блокировки - это обнаружение вторжений.
2. Снимите блокировку - в БД, удалите запись со своим IP-адресом из таблицы xxxxxx_itsec_lockouts. Проверьте, появился ли доступ к сайту
Примечание: В некоторых случаях, вы можете получать столько 404 ошибок, которые могут привести к немедленной блокировке снова. Если это так, попробуйте перейти к следующему шагу.
3. Узнайте, что является причиной ошибок 404 и исправьте их. Откройте логи iThemes, найдите запись с вашим IP-адресом. Каждая строка указывает на файл, к которому идет обращение с вашего хоста. Это и вызывает ошибки 404
Александр, в твоем случае рекомендую сделать немного иначе. Нужно начать с 3 пункта, и посмотреть в логах за что был заблокирован твой IP-адрес. Скорее всего это тоже может быть связано с большим кол-во ошибок 404. Посмотри, что там есть в логах
У меня была подобная блокировка блога. Не мог зайти в админ панель. Попробовал удалить плагин через FTP сервер, но не помогло. Затем восстановил блог из резервной копии, но как назло в моей БД была какая то ошибка и ничего опять не вышло, вообщем загубил себе блог. Хорошо, что на Хостенко служба поддержки адекватная, помогла мне восстановить сайт с минимальными потерями. Они мне еще посоветовали сменить шаблон и бесплатными больше не пользоваться.
Александр, ты, видимо, на странице Advanced пошаманил =) Те настройки не восстанавливаются даже после удаления плагина. Случаем не пытался сменить папку wp-content силами данного плагина?
P.S. видел твой новый шаблон, но все никак не могу добраться до твоих последних статей да покомментировать =)
wp-content папку не трогал, а вот во всех других настройках успел поковыряться)
Вообщем, куда не знаешь лучше не лезть, а пойти Faq почитать)
Вот это правильно =)
У меня время блокировки 15 минут. В сообщениях IP всегда разные, но периодически повторяются. Примерно месяц назад я удалил статью о интернет казино, вот именно ее и ищут (по моему робот). Она была указана в логах, давала ошибку 404.
Буду пробовать разбираться в настройках.
Александр, немножко не то. Удаленная страница - это понятно. Видимо она еще присутствует в индексе поисковиков, и на нее приходят люди. Нужно удалить ее из индекса (через панели вебмастеров Яндекса и Гугла).
Разные IP - это тоже понятно - это разные люди/боты.
Важно посмотреть именно твой айпишник в логах. За что блокировался именно он. И уже от этого пытаться плясать.
Специально проверял: "Загрузить файл", выбрал свою фото на компе, нажимаю открыть, вроде начинается загрузка и тут же появляется окно с надписью "ошибка загрузки". Сайт заблокирован, любая попытка перемещения ведет на пустую страницу с надписью: error. Сразу перехожу на почту, там письмо о блокировке. По окончании блокировки смотрел логи. Указан № хоста (но у меня таких номеров нет), причем он каждый раз другой. URL - похоже ведущий на изображение. В последней графе адрес моего сайта с добавлением админа.
В чем причина я не могу понять, может я как то запретил себе добавлять фотки? Я сделал скан этой части лога, может скинуть на почту? Причем запись повторяется в четырех строчках.
Александр, скан получил, по нему ничего понять пока нельзя. Нужно смотреть, что находится по ссылкам "Details" (там же, в логах). Чуть позже отвечу на почту. Или через скайп попробуем поискать проблему. Я тебе скину свой логин в скайпе на почту.
Всё выполнил, теперь опять могу зайти в админку и писать про эту ошибку небольшой пост))
Спасибо за помощь!
Пойду забегу к вам в гости =) Почитаю статью.
Александр Майер - Вы просто кудесник, реально помогли с этой проблемой по поводу того что самого хозяина выкидывает на страницу - "access denied", т.е. блокировки самого себя. Ваш рецепт по поводу стирания своего IP из базы данных в таблице - xxxxx_istec_lockouts.
В файле error_log своего сайта я не нашёл причину такой блокировки, так как не понимаю по англ. и не знаю служебных команд этого файла, но вроде как 404 ошибки там не фигурировало. Однако у меня есть два подозрения: 1) плагин Captcha не всегда работает корректно и меня, т.е. она не срабатывает с первого раза и со второго раза, а если третий раз не сработает меня сразу блокирует Better Wp Security, поэтому я его удаляю и в админку получается зайти. 2) у меня в браузере при загрузке вкладок одновременно загружаются 2 (закреплённые) вкладки с секретной адресной строкой (от Better WP Security соответственно), которые, итак ясно, сразу же загружаются как - "мой сайт/not_found", являются 404 ошибкой, значит две попытки уже использовано и для Better WP Secutity это сигнал к блокировке. Спасибо Вам ещё раз!
Ну вот, вроде разобрались. Я почти уверен, что дело в плагине капчи. В его настройках (если есть) сделайте, чтобы на странице авторизации капча вообще не отображалась. Страница секретная, там капча особенно не нужна. И даже если страницу авторизации и обнаружат, то сам iThemes сработает при неудачных попытках ввода логина/пароля и заблочит злодеев.
По поводу загрузки вкладок: лучше всего внесите секретную страницу в закладки и открывайте ее только когда понадобится.
И еще совет. Добавьте свой IP-адрес (если IP-адрес не постоянный, можете по маске добавить [если не знаете про это, напишите в обратную связь, помогу разобраться]) в белый список плагина. Тогда iThemes вас вообще банить и тревожить не будет.
Вот это да :) Саня ты прямо откликнулся на один из моих комментариев и сделал подробные пояснения по этому плагину.
P.S. - многие, в том числе и я, по натыкаем там чего попала и бывает приходится блог из резервной копии востанавливать ;)
Как говаривал Толстой: Так что, все в порядке. Главное иметь эти самые резервные копии
Неповрежденные резервные копии* :)
Да, да, это очень важное условие :)
Александр, большое спасибо! Это очень хорошо, что такая подробная статья. Там со многим нужно будет разбираться. Сегодня рано утром бегло прочитал, на выходных буду изучать.
Всегда пожалуйста, Василий. Нужно теперь причину вашей с Александром проблемы выяснить.
Сегодня более подробно ознакомился с настройками. Сделал еще пару настроек (не относятся к вставке изображений) и установил apple-touch-icon.png на сайт. Про иконку, наверное, раньше читал, но благополучно про нее забыл.
Решил попробовать выяснить причину блокировки. Стал добавлять тестовую запись с изображениями. Все происходит нормально, а раньше на 4 изображении появлялась ошибка. а затем "вылет" админ-панели.
Не удержался и добавил в черновик новую статью, а там штук 15 картинок. Все добавляется нормально, в штатном режиме.
Скорее всего эту проблему решил автор плагина. У меня такие настройки не были активированы.
Теперь нужно узнать как идут дела со вставкой изображений у Александра Викторовича. Все нормально у него или нет?
Василий, а ради эксперимента попробуй вновь удалить эппл-тач-икон, и попробовать написать черновик со вставкой картинок (хотя вряд ли в нем дело, он же в списке исключений).
Почему именно на четвертой картинке начиналась блокировка, так это потому что в Blacklist Threshold указано значение 3. Что-то вызывает/вызывало более 3 ошибок 404, поэтому включался блок.
Александр, есть несколько вопросов по настройкам плагина.
1. Filter Non-English Characters. У меня на сайте есть комментарии от владельцев сайтов с адресом на кириллице, типа "работа.рф". Включение этого пункта не приведет к ошибкам?
2. Remove File Writing Permissions. Я так понимаю, что после этого, другие плагины не смогут вносить изменения в файлы wp-config.php и .htaccess. А если мне нужно будет добавить туда (.htaccess) какие-то правила, то я смогу их ввести вручную или нет? Например, скачаю файл htaccess к себе на компьютер, сделаю, что нужно, а потом снова загружу на сайт.
Василий, что бы редактировать файлы wp-config.php и .htaccess, вам придется на некоторое время отключить плагин или в настройках отключить данный пункт защиты. Я так делаю на своем блоге, иначе не получается.
1. Нет, не должно.
2. А другим плагинам, как правило, и не нужно вносить изменения в эти файлы. Если же тебе самому нужно внести в них изменения, то просто на хостинге можно сменить права, откорректировать файлы, и установить вновь права 444. Все равно ведь эти файлы правятся через хостинг.
Если же скачивать файл к себе на комп и изменять его локально, то никаких проблем не будет. На винде ведь данные права не действуют, это *nix-овая тема.
Ну, или делать, как Александр Рус пишет (отключать при необходимости этот пункт настроек, затем заново включать).
У меня после установки плагина пишется сообщение Средней важности "A user with id 1 still exists." а где это изменить я не знаю. Нажимаю на фикс ит, но он меня куда-то непонятно кидает.
Виктор, кстати, да. Есть такое. Как я уже в камментах здесь писал - плагин за пару недель успел многократно обновиться, и почему-то сейчас в нем уже нет опции смены ID администратора. Остается только ждать когда они либо вернут опцию, либо уберут данное уведомление.
Вообще, смена ID админа не столь критична, тем более плагин его все равно менял на 0 , что легко вычисляется. Лучше воспользоваться специальными правилами для .htaccess, благодаря которым ни ID админа, ни любые другие ID вычислить стандартными путями не получится.
Вот они (добавлять в самый конец файла):
RewriteCond %{QUERY_STRING} ^author=([0-9]){1,}$ [NC] RewriteRule ^(.*)$ $1?author=999999 [L]Таким образом, URL вида bloginfo.biz/?author=x (где x и есть ID пользователя), будут перенаправлены на страницу 404 ошибки. Весьма полезный код, в том числе и для скрытия логина администратора (и других зарегистрированных пользователей, если они имеются), т.к. если указать в таком запросе ID админа (по умолчанию который и есть 1), то WordPress перебрасывает на страницу архива автора с этим ID. И тем самым палится логин админа.
Друзья! Передо мной сейчас стоит именно такая задача! ))
Однако приведённый вами код не редиректит у меня URL вида bloginfo.biz/?author=x
Я вписал его в .htaccess в корне сайта. Но запрос автора по-прежнему выдаёт логин администратора ((
Может есть ещё какие-то факторы, которые следует учесть? Ммм?!! >||
Ярослав, сложно сказать, почему у вас не сработало. У меня работает (можете проверить). Вставлял код в самый конец файла .htaccess
Вот это проработка материала! Большое спасибо! Буду разбираться и вдумчиво настраивать.
Ольга, вам спасибо за комментарий. Если что-то с плагином будет непонятно, спрашивайте, не стесняясь.
Проблема с картинками решилась. По видимому в последнем блоке я что то хватанул лишнего. Подкорректировал время и число попыток по блокировкам и убрал галки в последнем блоке, почти все. Все заработало нормально. Буду добавлять поштучно и только то в чем уверен. Тяжко без знаний Английского языка. Браузер переводит, но бывает так коряво, что не поймешь о чем речь.
Ну, то что в последнем блоке пришлось многое убрать - это не очень хорошо. И увеличение числа попыток тоже. Желательно все же устранить саму причину. Кстати, у Василия проблема исчезла. Либо из-за обновлений плагина, либо из-за того, что он добавил на сайт файл apple-touch-icon.png. Кстати, у тебя этого файла тоже нет, может в этом причина?
Число попыток я не увеличивал, максимум три, просто время не совсем правильно поставил. Файл этот нужно сделать, только он не где в ошибках не фигурировал. А защиту я не сильно ослабил, как говорит плагин.
А вообще еще разбираться и разбираться. Я что то в отчетах вижу файлы моего магазина и мои действия там. Он что решил работать на два сайта?
Нет, такого быть точно не должно. 1 сайт - 1 плагин. Пришли мне на почту текстом, что пишется по ссылкам "Details" в логах. Может быть что-то там увижу.
Письмо я отправил. Точно скопировал то , что открывается по ссылке. Я в этом совершенно не смыслю.
Сейчас все работает. Даже спама стало меньше. Сегодня обновился WP до версии 3.8.2. Обновление прошло полностью автоматически, без моего участия. На почту получил сообщение.
Александр, возможно, что разработчики сами исправили эту проблему. У Василия тоже все нормализовалась.
Письма получил, оба. По "Details" ничего толкового сказать не могу, ожидал нечто другое там увидеть. А по второму письму отвечу сегодня, немного позже.
Большое спасибо автору за инструкцию. Я из новеньких и без языка, еще осенью нашел плагин - нутром чую, что защита мощная и комплексная, а разобраться в тонкостях настройки не могу. Он меня тоже первое время самого банил, но я нашел выход путем простой замены файла .htaccess, но это в прошлом. А тут на вашем сайте такой подарок - такая подробная инструкция - я полгода, собирая отовсюду данные по настройке плагина, и половины не насобирал. Еще раз большое спасибо, здоровья и успехов!
Анатолий.
Спасибо за развернутый отзыв. Рад, что статья принесла пользу. Всех благ вам!
Никогда не пользовался подобными плагинами, судя по описанию - iThemes Security достаточно мощный плагин. Наверное требовательный к ресурсам сервера? Кстати, будет ли он работать на виртуальном хостинге Nginx или только на Apache? Встречался с некоторыми плагинами, которые отказывались у меня работать...
Плагин действительно достаточно серьезный. Особенно для нас, простых блогеров. Потому как многие блогеры в премудростях серверных технологий, мягко говоря, ничего не понимают. А тут плагин все конфигурирует и прописывает за нас. Отсюда, кстати, и его очень низкое потребление ресурсов. Ведь по сути он всего лишь прописывает свои правила в .htaccess (если брать только основной функционал).
Работает и на апаче, и на lightspeed, и на nginx. Но в случае с nginx может потребоваться ручная конфигурация (так сказано в официальном описании). На моем хостинге, как я понимаю, стоит nginx перед apache, и все работает "из коробки".
Плагином пользуюсь давно, но некоторые функции не использовал так как не знал в каких случаях их нужно включать. Нормальной русификации не было, как впрочем и инструкций по настройке. Теперь же все встало на свои места - пришло понимание что и как работает. Пошагово настроил все под себя с Вашей помощью. Изложено все очень понятно. Огромная благодарность от меня! Вот такие подробные инструкции и нужны. А то бывает ищешь информацию, а её толком нету. Десятки блогов обходишь, а там примерно одно и то же поверхностно написали, ровно столько, сколько и самому понятно.
PS Здесь так много интересующих меня тем, что сразу всё и не прочесть. Даже решил - подпишусь на обновления (впервые в жизни). До сих пор никогда нигде подписан не был.
Сергей, огромное спасибо за развернутый комментарий. Рад, что статья оказалась полезной. Буду стараться и дальше.
Извиняюсь, на одном из моих сайтов обновил плагин и после небольшой донастройки и сохранения получаю сообщение вверху "Unable to release a lock on your .htaccess or nginx.conf file. If the problem persists contact support."
Кто нибудь знает на что он ругается? Проверил htaccess, он доступен для записи плагином, а файла nginx.conf я не нашел. У меня виртуальный хостинг "Бест-Хостер", с cPanel.
И все же плагин ругается на то, что для него заблокирован доступ к .htaccess. Проверьте права на этот файл через FTP или через ПУ хостингом. Выставьте права 644, а в настройках плагина не забудьте активировать опцию "Remove File Writing Permissions". Должно помочь. Если не поможет, то обратитесь к хостеру.
Выставить права 644 через FTP я пробовал в первую очередь, галочка "Remove File Writing Permissions" тоже стоит. После сохранения настроек файлу .htaccess снова возвращаются права 444 и снова вверху сообщение от плагина "Unable to release a lock on your .htaccess or nginx.conf file. If the problem persists contact support."
Кстати, после применения настроек и получения вышеописанной ошибки захожу в диспетчер файлов (вебинтерфейс хостинга) и смотрю что время последнего редактирования - минута назад. Проделывал несколько раз, результат такой же. Что интересно, сверяю содержимое .htaccess до правки и после правки - абсолютно нет изменений, даже если изменить некоторые настройки в iThemes Security. Вот совсем непонятно теперь применились ли указанные мной настройки или нет, защищен ли сайт вообще..
А если не активировать опцию "Remove File Writing Permissions", и вручную выставить права 644, то никакого сообщения нет?
А вообще, лучше будет обратиться в саппорт хостинга. Возможно имеется какой-то конфликт с конфигурацией сервера. Кстати, в официальном описание есть указание, что при работе с плагином может потребоваться ручная конфигурация веб-сервера NGINX (тот самый nginx.conf, о котором говорится в вашем сообщении). Так что, определенно следует обратиться к хостеру.
По второй части комментария. Не каждая опция плагина вносит изменения в файл .htaccess. Так что - это не показатель. Для проверки можете поставить iThemes Security на тестовый сайт, настроить также, как и на основном, и сверить оба .htaccess
Еще одна неприятная новость от плагина - его новая вервия перестала отправлять бэкапы БД! Проверил письма с других своих сайтов где обновлен iThemes Security - везде письма без прикреплённого бэкапа. Только текст ""Attached is the backup file for the database powering http: // ***.ru taken Thursday, April 10th, 2014 at 4:02 pm.
Даже на сайтах где обновление и донастройка прошли без проблем бэкапы так же не отправляются.
Честно говоря уже совсем не рад этим изменениям и обновлениям. Если раньше работало, то после обновления какие то косяки появились, плюс обновлять и перенастраивать плагин придется на всех 70 сайтах которые я обслуживаю.
Да уж, немало "сюрпризов" преподносит этот плагин.. Но у меня лично бэкапы нормально приходят, на всех трех активных сайтах. 3 - это не 70, конечно. Я вот, что думаю. Не стоит пока каждое обновление сразу же на всех сайтах ставить, выждать немного, когда ситуация с багами и обновлениями устаканится. И уже потом постепенно везде обновиться до текущей стабильной версии. А то я как представлю - 70 активных сайтов и обновления плагина чуть ли не ежедневно...
Да я так и делаю, на 4-5 сайтах обновил, а остальные пока не трогаю.
Кстати, есть одно решение для случаев, когда админишь множество сайтов - прописать функцию в конфиге движка для автоматического обновления плагинов. По умолчанию она деактивирована, но возможность такая имеется (начиная с версии WP 3.7). Лариса Веб-Кошка подробно про это писала уже: http://web-koshka.ru/wordpress/osnovy/wordpress-3-7.html
Во многих случаях это очень удобно. Но конкретно в случае с iThemes Security как-то опасливо обновлять такое количество сайтов на автомате. Мало ли что опять произойдет.
Здравствуйте Александр! Возникла проблема с плагином. Сначала я мог зайти на любую из вкладок настроек плагина, а теперь, видимо после какого-то очередного обновления плагина, меня выкидывает на 404 ошибку при заходе на вкладку "Logs". Подскажите, где возможно я ошибся с настройками? А может ждать обновления плагина? Хотя уже было дважды обновление, и всё на своих местах, т.е. не работает вкладка "Logs".
Доброго времени суток, Сергей. Увы, но я даже примерно не знаю "где копать" в вашем случае. О такой проблеме впервые слышу, и даже в англоязычном интернете не встречал. Я даже не могу сообразить, почему из админки вас перебрасывает на страницу 404. Мистика какая-то
И у меня такое случилось на одном из сайтов. Может быть кому то поможет. Сделал вот что.
1. зашел через FTP и переименовал папку плагина на Better-WP-Security000
2. после этого уже смог зайти в админку,
3. зашел в плагины, Better WP Security после переименования был деактивированным,
4. было уведомление о новой версии, я обновил, затем активировал его.
И после этого все стало как надо.
Сергей, все правильно. По большому счету, это значит удалить плагин, и установить его заново. Типа с нуля. И во многих случаях, как показала практика за последние дни, такой вариант действительно может быть весьма действенным.
Спасибо за СУПЕР-статью! Мне вот непонятно с этим пунктом (Если после скрытия админки у вас возникли проблемы с доступом в нее, то возможной причиной может стать несовместимость с темой. Для того, чтобы исправить это, воспользуйтесь опцией "Enable Theme Compatibility". ) Как ей можно воспользоваться, если в админку нельзя попасть?
Юрий, если так получилось, что плагин заблокировал вас самого, то следует либо дождаться разблокировки, либо удалить через FTP папку с плагином, либо удалить строку из таблицы БД с вашей блокировкой. Естественно, последний вариант наиболее правильный. Чуть выше в комментариях я уже писал о том, как это сделать (перевод официальной рекомендации iThemes). Таким способом можно всегда снять блокировку с себя или с любого другого пользователя/хоста, независимо от причины блокировки. Ну, а затем уже искать эту самую причину.
Хороший плагин! Вообще в последнее время очень важно уделять внимание безопасности блога, очень плохо если его владелец не заботиться об этом
Совершенно верно. Не стоит пренебрегать безопасностью.
Спасибо. У меня ещё вопрос по (Error Threshold – порог допустимых ошибок). Там написано (Но более правильным решением будет привести все в порядок – создать фавикон, apple-touch-icon.png, robots.txt, sitemap.xml и т.п.). Меня интересуют последние последние 4 файла на вашем скриншоте, (фавикон, apple-touch-icon.png, robots.txt, sitemap.xml я уже сделал). Мне их нужно создать самому, ничего в них прописывать не надо? И куда их положить? Если можно поподробней. Спасибо.
В данном контексте на сайте рекомендованы только лишь фавикон, роботс, сайтмэп, и эпплтач. Остальное - это более, чем индивидуально. Те файлы, за которые вы интересуетесь, однозначно второстепенны. Я реально даже не знаю, что это за файлы =))
Спасибо. Это хорошо, что они не нужны. Чем меньше, тем лучше. Ждём от Вас что-нибудь новенького.
Новенькое будет, конечно, но не знаю как скоро =)
Странно, а у меня он не обновился. В поиске нашел, а вот обновы не было.
Может стоит какой-то плагин, типа Disable All WordPress Update? Или может в wp-config.php прописывал запрет на автообновление? Другие плагины обновляются?
Давненько им пользуюсь, отличный плагин. Обновился без проблем, как и раньше время от времени присылает отчеты о блокировке ботов, которые в админку пытаются войти :-)
У меня тоже все прошло без происшествий на трех сайтах. Тьфу, тьфу, тьфу =)
Привет. Не заметил такую вещь, что при скрытой админке приходится дважды вводить пароль?. Первый раз ругается, на второй пускает. Проверял на разных блогах и компах. Не пойму в чем дело.
Привет. Да, замечал такое, но только на одном сайте. Грешил на косяки с автовводом KeePass. Оказывается не у одного меня так. Но после обновления на 4.0.21, как мне показалось, эта проблема исчезла. Или у тебя до сих пор появляется? В этом обновлении, кстати, есть какое-то исправление по части hide backend и зацикливания. Может это оно и есть?
нет, не в нем дело... не в обновлении. Грешу на малвареантималваре. Кстати, в курсе, что они значтельно обновили свою программу?
Не, MBAM тут вряд ли при делах. Кстати, недавно специально по нескольку раз на трех сайтах пробовал залогиньтся/разлогиниться, все в порядке. Проблема не наблюдалась.
MBAM, конечно, меня сегодня чуть в ужас не поверг, когда обновил. Перевод - это нечто)) Да и интерфейс стал не ахти. Хотя функционал немного прибавился. В том числе и реклама своих продуктов появилась, и это в премиум версии, что как-то странно выглядит.
Но это 99% не он виновник проблемы.
ушла проблема после обновления до 4.1.3. я про двойной ввод верного пароля
Я тоже вроде больше не наблюдаю
Для меня также актуальна данная проблема (после первого раза не могу в админку попасть, только после повторного ввода логин/ пароль) и до сих пор я от этого не могу избавиться.
В последнее время меня частенько не пускает данный плагин в админку, при попытке зайти я вижу лишь надпись eror/
Если раньше это случалось раз в месяц, то за последнюю неделю это уже 4 случай, это очень меня напрягает))
Сейчас только нашел куда внести свой ip в белый список. Вот опять пока не могу войти в админку и изучаю похожие проблемы у вебмастеров.
Тут по одним комментариям к посту можно диссертацию защитить по данному плагину))
Проблема с "ошибкой" ввода логина/пароля так и остается актуальной до сих пор.
Саш, привет! Слушай, случайно наткнулся на такой вот плагин All In One WP Security - этакий комбайн, что совмещает в себе Акимет, iThemes Security и антивирус. Ну так, на первый взгляд. Не пользовался таким?
Привет. Я тоже недавно про него как-то случайно узнал. Судя по описанию и функционалу очень даже хороший плагин. А вот потестировать я его еще не успел. "Отложил" на потом.
All In One WP Security отличный плагин пользуюсь им давно, в нем все есть для защиты
Да, действительно целый комбайн для защиты.
Александр! Подскажите, надо ли файл config.php перекидывать на один уровень выше в директории сайта, а старый config.sample.php удалять ?
Sample можно и удалить. А вот wp-config.php перекидывать никуда не нужно.
Добрый день!Работу проделали колоссальную.Спасибо вам за это!!!
Я решила сначала настроить плагины все,а потом уже заняться наполнением контентом.
У меня вопрос: В settings-database backups-Backup Method-написала чтоб отправляли на e-mail.Ниже в Backup Location оставить все как есть или нужно указать сайт куда отправлять.
Здравствуйте. Спасибо за благодарность.
В поле Backup Location ничего менять не нужно. В нем указывается путь, где будут храниться бэкапы непосредственно на хостинге. Но т.к. вы выбрали только E-mail, то не обращайте на это поле внимание.
Есть такой метод, Саш. Когда файл конфигурации поднимают на уровень выше (то есть за пределы каталога public_html). На cpanel точно работает.
Но вот с в связке с этим плагином лучше не делать такой финт)
Я когда-то слышал про такой способ. Но думаю в данном случае он будет лишним, ведь файл вп-конфиг и так достаточно защищен. Хотя метода интересная
Такой вопрос : почему при скрытой админке не работает аутентификация через htaccess.
то есть или заходим сайт.com/wp-admin и тогда запрашивается аутентификация, или скрываю админку с помощью iThemes Security и через сайт.com/Login Slug сразу попадаем на стандартный вход в админку. а мне надо и то и другое
помогите, пожалуйста!
Лена, очень интересный вопрос. Я вряд ли смогу ответить точно, но давайте попробуем порассуждать. Здесь определенно идет конфликт в правилах .htaccess
Аутентификация через веб-сервер прописывается примерно так:
То есть это значит, что при обращению к файлу wp-login.php потребуется аутентификация.
Наш же плагин прописывает еще и такое правило:
То есть, файла wp-login.php как бы и не существует вовсе.
Чтобы работали сразу оба метода, нужно изменить вот эти строки
таким образом, чтобы веб-сервер просил аутентификацию не при обращении к wp-login.php, а при обращении к Login Slug. Как это правильно сделать, я к сожалению, не знаю. Надо будет почитать об этом, потестировать (или спросить у кого-нибудь). Если найду ответ, то отпишусь здесь же.
А вообще, зачем вам двойная авторизация? Через веб-сервер будет вполне достаточно. Или же наоборот, через плагин.
спасибо за совет, хоть буду знать теперь в каком направлении искать.
а двойная авторизация была на сайте до обновления плагина, потом все испортилось - вот я и хочу вернуть как было ))
Да, раньше все работало, пока плагин не обновился.
Можно, конечно, пойти и обходным путем: на тестовом сайте скачать раннюю версию плагина, установить, и посмотреть, какие конкретно правила прописываются для маскировки админки. Скопировать их, и вставить в текущий .htaccess (внеся соответствующие изменения, естественно), а в iThemes Security функции маскировки отключить. Получится, что и веб-серверная аутентификация и маскировка админки прописаны вручную. Как вариант, можно и к такому прибегнуть.
Спасибо, за такую подробную инструкцию, долго пришлось искать статьи как настроить данный плагин. Нашел только у Вас. Внимательно читая инструкцию, настроил плагин. Скрыл свой вход в админку и не смог попасть. В результате отключил. Нет времени разбираться. Позже сделаю.
У меня вопрос следующий. Зашел на сайт с компьютера на работе. Через короткое время , при переходе на другую страницу вместо сайта белый лист и левом верхнем углу написано error. На домашнем компе сайт работает. В чем причина? И как можно исправить?
Спасибо
Игорь, спасибо за развернутый комментарий. Сокрытие админки должно работать, за исключением каких-то нестандартных конфигураций сервера и т.п.
Белый экран "error" - это значит плагин вас блокирует. По какой причине? Так просто сказать невозможно. Необходимо смотреть логи и т.д. Причиной может быть все, что угодно, вплоть до наличия на рабочем компе какого-нибудь "вируса". Как вариант - попробуйте добавить IP-адрес рабочего компьютера в белый список плагина. Это не устранит саму причину, но блокировки должны исчезнуть. Но причину все-таки лучше устранить. Если что, пишите через обратную связь. По мере возможности постараюсь помочь.
В обновлении в графе Glabal Settings появился пункт Disable File Locking. Нужна здесь галочка или нет?
Эдуард, разработчики не рекомендуют включать данную опцию, если все и так работает корректно.
Здравствуйте, Александр.
Снова не получилось настроить iThemes Security. Дохожу до тонких настроек, активирую Filter Suspicious Query Strings in the URL и все, белый экран с error в админке и на сайте ( при переходе на страницу). Не уверен, но эта функция думаю виновата. При установке плагина у меня красным только одна строка, по-моему настроить бэкап базы по расписанию. После включения, остаются поля желтого и синего цвета. Можно оставить так? Сейчас переименовал .htaccess и удалил плагин. Не пойму, в чем причина.
Добрый день. С праздником!
Ну, если уж не дает эта опция нормально работать, то не включайте ее (но желательно ее все-таки использовать). Хотя странно это все. Если вы говорите про сайт http://woodsmen.ru, то на нем нет таких страниц, которые могли бы конфликтовать с этой настройкой.
Желтые поля - это не особо критичные замечания, но желательные к исправлению. Можно работать и так.
Спасибо, за быстрый ответ. Правил калькулятор, только сейчас заметил ответ. Да, сайт этот. Сделаю так - поставлю, пройду первоначальные настройки (3 кнопки), потом исправлю красное поле (оно должно быть одно) и проверю. Если по истечении времени закроет доступ, тогда не знаю в чем причина. А жаль, плагин хороший.
С праздником.
Конечно, пробуйте, экспериментируйте. Надеюсь, все получится. В крайнем случае, можно обратиться к хостеру за поддержкой.
Добрый день Александр! С праздниками! Можно вопрос? Он простой, но что то я не пойму. Много разговоров о скрытии админки, но не пойму что это значит? Например у меня мета давно убрана, захожу по ссылке, через ВП-админ, но у меня еще и дополнительная защита от хостинга.
Это считается скрытием админки или что то другое?
Александр, приветствую! Рад видеть. Скрытие админки, в первую очередь, нужно для того, чтобы на сайт не производились брутфорс-атаки (подбор пароля). Методы скрытия бывают разные. Если при заходе по адресу вп-логин (вп-админ) появляется дополнительное окно для авторизации, а не стандартная вордпрессовская страница входа, то этого обычно бывает достаточно.
Ну за такую инструкцию не сказать спасибо нельзя просто, что я и делаю.
Автору респект и пожелания удачи во всех начинаниях.
Непонятки с плагином есть, но надоть еще почитать, думаю от рук идет.
Спасибо
У меня конфликтовал с Seo by Yoast. Не давал бэкапа.
Дезактивировал Seo с предварительным сбросом до заводских настроек.
Затем дезактив. iThemes Sec. и активировать снова.
И все стало работать?
Стало. С выключением Yoast. Но допускаю, что косячил в настройках.
Прям как в одной известной компьютерной поговорке: "Сем бед, один Reset" =)
У меня проблема - после обновления плагина на главной не отображаются миниатюры записей. Причем если я вхожу в панель администратора, то миниатюры на главной вижу, а простой пользователь видит только квадратики. Не могу понять где я ошиблась в настройке плагина, когда плагин отключаю - миниатюры выводятся нормально.
Татьяна, я слышал про такую проблему, но, к сожалению, точного ее решения не знаю. Попробуйте поочередно включать/выключать некоторые опции плагина в разделе System Tweaks. Но помните о том, что некоторые опции в этом разделе очень важны для обеспечения защиты.
P.S.: если найдете причину, то отпишитесь, пожалуйста, в чем именно крылась проблема. Скорее всего, с плагином конфликтует сама тема.
Здравтсвуйте.
Сделал настройки в плагине, убрал только красное предупреждение. Сайт работает, админка тоже, но примерно через час, полтора при переходе на другую страницу сайта или в админке снова белый экран и error. Утром, на следующий день все открывается. Помогите разобраться, в чем причина.
Спасибо
Саш, если не против, отвечу)
отключите детектирование ошибки 404.
Скорее всего в ней дело. Это в разделе settings.
Спасибо, Дмитрий. Да, здесь срабатывает именно 404 detect. Но отключать эту опцию не есть правильный выход. От самоблокировок это, конечно, избавит, но от самих ошибок 404 нет. А это и нагрузка на сервер от самого себя, и от парсеров и ботов. Лучше, конечно, выявить, что именно вызывает ошибки 404.
Ничего не понимаю. Вернул через пару часов прежнее имя файла .htaccess, все работает, страницы открываются. Такое впечатление, что плагин зависает и на время дает сбой. Может я превышаю время нахождения в админке? Не знаю, что и думать.
Просто время бана истекает через какое-то время и доступ возвращается. Как вариант, можно добавить свой IP-адрес в White List.
Сейчас сделаю, проверим. Спасибо, за совет.
Если отключение ошибки 404 поможет, тогда я и желтые поля уберу))!!
Может кто-нибудь уже сталкивался с таким багом после установки и настройки iThemes Security: в админке вордпресса идём во вкладку «плагины» далее «добавить новый», в поле «поиск плагинов» вбиваем название какого-нибудь плагина и жмём поиск - вместо результата поиска перебрасывает на 404 страницу...
Проверил на 2-х разных сайтах - результат один и тот-же. На всех сайтах стоит последняя версия WP3.9 и версия самого плагина 4.1.5
Я лично с этим не сталкивался, но слышал про такой косяк. Но как его "лечить", увы, не знаю.
P.S.: да уж, обновление и ребрендинг =) Столько гемора людям принесли)) Раньше все как часы работало.
Самая подробная инструкция, которую я когда-либо видел)) Нашёл её через яндекс, воспользовался, а только потом увидел, что это ты, Александр. Респект!)
Привет, Сергей! Рад видеть. И спасибо за оценку статьи.
По вашей инструкции поставила плагин. Он у меня после обновления видимо перестал работать. Ошибку 404 перестал показывать в логах. Если честно не могу понять работает работает он или нет. Сегодня переустановила и перенастроила, но все по-прежнему.
Здравствуйте, Ольга.
Для начала убедитесь, что в разделе "Settings" в блоке "404 Detection" у вас стоит галочка напротив "Enable 404 detection". Что касается того, работает плагин или нет, то основную часть его "деятельности" можно увидеть в файле .htaccess - там должно быть множество различных записей. Начинаются они с комментария # BEGIN iThemes Security и заканчиваются # END iThemes Security.
В целом, если работа сайта после установки и настройки не нарушена, то, вероятнее всего, что плагин работает корректно.
И еще убедитесь в том, что у вас стоит галочка в пункте "Allow iThemes Security to write to wp-config.php and .htaccess." - это тоже на вкладке "Settings", самый первый пункт.
Спасибо за подсказки , развернутую и очень подробную статью. Все получилось, настроила плагин.
Ольга, рад, что смог помочь, и что у вас все получилось
Здравствуйте, Александр. Спасибо за очень информативную статью. Вы проделали огромную работу! Начала заниматься безопасностью своего блога и обнаружила вашу статью. Теперь хочу установить данный плагин у себя. Но не уверена, что он не будет конфликтовать с файлами, которые я вручную прописала и добавила. Я говорю о файлах .htaccess и .htpasswd, которые я добавила в папку wp-admin. У меня на блоге я прохожу двойную авторизацию (две пары логинов и паролей, чтобы зайти в адмиy панель. При установке данного плагина, мне нужно удалить мои ранее созданные .htaccess и .htpasswd из wp-admin?
У меня вот что еще дополнительно прописано в корневом файле .htaccess. Мне это убрать или можно оставить?
# Code for protection from malicious requests
Options +FollowSymLinks
RewriteEngine On
RewriteCond %{QUERY_STRING} (\|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
RewriteRule ^(.*)$ index.php [F,L]
# End code for protection from malicious requests
Заранее спасибо за любую помощь.
Здравствуйте, Светлана. Спасибо за оценку статьи. К сожалению, двойная авторизация вместе с этим плагином (после его обновления) не работает. Точнее не работает при стандартных настройках авторизации через веб-сервер для WordPress. Там надо вносить правку в правила, но честно сказать, я пока не знаю как именно. С другой же стороны, если задействовать в этом плагине скрытие админки, то двойная авторизация как бы и не нужна вовсе.
А что касается указанных вами правил из корневого .htaccess, то их можно смело удалять. Плагин запишет свои, более развернутые.
При создании бэкапа базы данных через плагин вылезает ошибка: Something went wrong with your backup. It looks like another process might already be trying to backup your database. Please try again in a few minutes. If the problem persists please contact support. С чем это связано?
Похоже на то, что либо не хватает ресурсов, либо, как собственно и написано, в этот момент БД занята каким-то другим процессом, делающим бэкап. У тебя эта ошибка постоянно появляется?
У меня настроено сохранение бэкапов по расписанию, но оно не работает. Ошибка появляется постоянно. Ещё заметил, что у меня не было директории wp-content/uploads/ithemes-security. Это критично? Сейчас создал её вручную.
У тебя нет никаких других плагинов или скриптов для создания бэкапов? Может конфликт где-то.
/uploads/ithemes-security - там хранятся логи и бэкапы (если хранить бэкапы на сервере). Она должна была создаться автоматически, хотя бы для того, чтобы хранить в ней логи. Если, конечно, ты не указывал другой путь.
А вообще, может быть стоит снести плагин, почистить БД, и установить его заново?
Подскажи, пожалуйста, как лучше очистить БД? Плагином?
Могу порекомендовать плагин WP-Optimize. Сам им пользуюсь. Вполне прилично удаляет лишнее (ревизии постов, черновики, спам, различные временные настройки) и оптимизирует таблицы БД. Кстати, о временных настройках. Если решишь воспользоваться этим плагином, то там увидишь некоторые пункты, которые выделены красным цветом. Это опции, перед выполнением которых рекомендуется сделать бэкап БД, чтобы если вдруг, как говорится. Но по собственному опыту скажу, что всегда смело отмечал и "красные" пункты, и никаких проблем не возникало.
Спасибо!
Всегда пожалуйста
Я никогда не комментировал ни один пост ни в одном блоге такого рода, хотя и занимаюсь сайтостроением уже не один год, но ваша запись действительно очень достойная!
Огромное спасибо!
Спасибо большое! Очень приятно слышать.
Спасибо за эту инструкцию!
В создании сайтов новичок. Сайт новый. Первым делом установила данный плагин и воспользовалась советом по изменению контент-директории для новых сайтов. Но возникла проблема. Теперь все загружаемые картинки просто не отображаются. Не подскажите как решить эту проблему?
Здравствуйте, Татьяна. Скорее всего, нужно в базе данных произвести замену всех упоминаний wp-content на новое значение. А также посмотреть в файле wp-config - везде ли эта директория изменена. Если ничего не получится, то попросту откажитесь от этой опции и используйте стандартную директорию. В будущем меньше проблем будет. Хотя для безопасности - это хорошая функция, но не первостепенная.
Александр, у меня конфликт Itemes Security с плагином Anti-XSS. Скажи, нужен ли Anti-XSS или его можно смело удалять?
Сергей, Anti-XSS можно смело удалять. Он не нужен, если есть iThemes Security. Да и вообще есть мнение, что начиная с WP 2.5 (если не ошибаюсь в версии) данный плагин без надобности.
Ок, спасибо за совет!)
Спасибо огромное вам за статью!!!Я установила плагин на сайт 2 недели назад,все было нормально.Неделю назад начал блокироваться сайт.При переходе на страницу писали error.Потом через какое то время блокировка снималась.Не знала как решить проблему и весь сайт удалила.Восстановила с Backup.Настроила все по вашей подробной инструкции.Теперь вверху мне пишут мой ip адрес и что сайт заблокируется через 12.58 часов.Я правильно понимаю,что мне надо прописать мой ip в white list?Проблема в том,что у меня нет постоянного ip адреса.Что вы посоветуйте? Спасибо.
Здравствуйте!
Начнем с того, что раз появляется/появлялось "error", то это все-таки нехорошо. Плагин по какой-то причине вас блокирует/блокировал. Поэтому желательно выявить причину блокировок, а не снижать порог для этих самых блокировок. Но, эта задача далеко не тривиальная. В целом - нужно смотреть логи: почему и за что именно вас плагин блокировал.
Подобные блокировки, как вы сами убедились, временные. И, если вдруг такое произошло, то инструкция по разблокировке самого себя описана вот в этом комментарии. Ну, это на всякий случай. На будущее, чтобы не "сносить" плагин и т.д.
Теперь самое интересное. Вы пишите:
Правильно ли я понимаю - вы пишите про блок "Don`t Lock Yourself Out"? Там еще синяя кнопочка есть, типа внести временно мой IP в белый список? Ну и после нажатия на эту кнопку пишется что-то типа: Your IP Address, 123.123.123.123, is whitelisted until 2014-05-29 19:03:40. Вы про это?
Если да, то это значит, что указанный IP-адрес добавлен в белый список до указанного времени (после until). Или у вас какие-то другие предупреждения и уведомления?
Вообще, лучше изначально добавить свой IP в white list. Но, т.к. у вас нет постоянного IP-адреса, то его можно внести по маске. Как это делается? Ну, смотрите. IP-адреса состоят из 4-х октетов (для простоты скажем, что из четырех чисел, разделенных точками, типа: 123.123.123.123). У вашего провайдера, наверняка (но не факт), два первых остаются неизменными, а два последних меняются. Так вот, чтобы добавить в белый список динамические ("меняющиеся") адреса, нужно добавить их примерно так: 123.123.*.*, где первые два октета неизменны и указываются явно, а вторые - помечаются "звездочками". То есть вместо звездочек могут быть любые числа. Но, стоит понимать, что и любые другие IP-адреса из этих сетей также НЕ будут блокироваться.
Наверное написал слишком сумбурно. Так что, если вдруг не совсем понятно, напишите мне через обратную связь, постараюсь помочь по этому вопросу более детально.
Спасибо огромное за подробный ответ!!!Даже не ожидала)
Пишут предупреждения именно так как вы описали.Попробую сейчас все прописать в white list.
На счет блокировки тоже разберусь.Еще раз спасибо!
Всегда рад помочь, чем могу =)
Я договорилась с провайдером,он мне поменяет на статичный ip.Потому что у меня никак динамичные не повторяются.Пока он мне сменит думаю пройдет 2-3 дня.А проблему пока решила так:Когда приходит время блокировки сайта я деактивирую плагин и сразу активирую.у меня таким образом дают еще 24 часа до блокировки.Настройки при этом не сбрасываются.Может быть кому нибудь пригодится.
Статический IP - хорошее решение.
А вот насчет 24 часов до блокировки вы не совсем правильно поняли. Это наоборот отсчет того времени, сколько ваш IP-адрес будет в белом списке, а не время до его блокировки. Так что, отключать и включать плагин не нужно.
Хорошо) Спасибо.Учту.Еще 1 вопрос:После 24 часов он переходит в черный список?мне немного не понятен смысл тогда.
Почитала думаю все на вашем сайте.Вы очень грамотно пишите и везде очень подробно отвечаете(не всегда встретишь такое,обычно отписываются)
Удачи вам!И процветания всех ваших проектов!
Виорика, спасибо на добром слове!
Нет, после 24 часов он убирает вас из белого списка. Но ни в какой блэк-лист вы не вноситесь. Тут речь о черном списке вообще не идет. Либо вы работаете, как и работали, либо вносите свой IP-адрес в белый список (ну так, на всякий случай)
Почему при включенном режиме Гоу Эвей блокируется не только вход в админку, но и любой вход пользователям и регистрация? Это глюк иля я не то настроил? Как входить другим авторам и простым зарегистрированным пользователям в это время? Спасибо!
Павел, Away Mode полностью блокирует админку в указанное время, в т.ч. и регистрацию пользователей, авторизацию на сайте и т.д. Так что, если для вас это критично, то данную опцию использовать не стоит.
1. Есть ли какой-то плагин, который может блокироватьтолько администрировнаие сайта, но давать возможность логиниться пользователям, которые имеют права доступа менее, чем изменение настроек сайта, и комментировать либо размещать информацию?
2. Есть ли секретный способ, используя например доступ к хостингу, отключить блокировку по Away Mode, если случайно забыл про нее, заработался и попал в "запрещенный режим"?
1. К сожалению я такого плагина не знаю. Да и чисто теоретически такое невозможно: если админка заблокирована, то по идее и авторизоваться на сайте невозможно. Могу порекомендовать вам отключить редактирование файлов в админке (посредством этого же плагина), а также четко распределить права для зарегистрированных пользователей, т.е. дать им минимальные права на размещение информации и все. Т.е. никаких технических манипуляций с сайтом они сделать не смогут.
2. Да, есть такая возможность. Нужно лезть в БД. Алгоритм действий примерно такой:
- Соединяетесь с БД через phpMyAdmin
- Вверху ищете вкладку "Поиск", заходите в нее.
- В поле вбиваете "itsec_away_mode" (без кавычек)
- В поле, которое чуть ниже выделяете таблицу "префикс_вашей_БД_options" и жмете ОК.
- После завершения поиска там будет написано типа: "найдено столько-то соответствий". Жмите "Обзор".
- Находите строку "itsec_away_mode"
- В ячейке справа от нее будет что-то вроде
a:4:{s:7:"enabled";b:1;s:4:"type";
i:1;s:5:"start";i:140100;s:3:"end";i:140600;}
- Так вот в этой ячейке замените значение enabled на disabled (просто как в обычном текстовом редакторе)
Все, функция Away Mode таким образом будет деактивирована. Активировать ее потом можно будет по обычному, из ПУ плагином.
Может показаться, что эта процедура сложная и длительная, но на самом деле все проще простого, попробуйте (если что-то осталось непонятным, спрашивайте). Во всяком случае это намного проще, чем удалять плагин, чистить .htaccess и т.д. (тем более это не поможет в данном конкретном случае).
P.S. Перед манипуляциями с БД не забудьте сделать свежую резервную копию оной. На всякий пожарный случай =)
Спасибо, как раз все плнятно. Я что-тл в этом роде и предполагал, только не знал, что именно и в какой таблице искать.
Ок, если эвей мод блокирует любой вход, то можно ли сделать так, чтоб при попытке входа пользователь перенаправлялся на специальную страницу с текстом что-ьо вроде "простите, в админпанели идут проф.работы. залогиниться вы сможете в такое-то время." Просто когда тупо не грузится страница логина - это даже меня озадачило, а потенциальных клиентов вовсе оттолкнет.
Павел, чисто теоретически, конечно можно (в веб-программировании вообще мало невозможного), но я даже близко не знаю, как именно это осуществить. Если очень нужна именно такая реализация, попробуйте обратиться к специалистам-фрилансерам. Я не думаю, что за такую работу много возьмут. Если это не столь критично, то поступите так, как я описал выше: проследите за правами пользователей (чтобы среди них не было админов) и отключите редактирование файлов в админке. В большинстве случаев этого вполне достаточно.
Поставила плагин. Но помимо первой ошибки, еще выдает "The admin user still exists." - вот такую. Что нужно сделать с этим. Фиксить нажала, но там еще куча всего красного и страшного, и не понятного. Просто от балды нажимать не хочется.
[File Change Detection] Обнаружение изменений файлов
В этом разделе не могу найти кнопку "scan now" Может убрали или я слепая?
[Hide Login Area] в разделе в самом низу есть еще одна настройка:
Custom Login Action
Custom Action:
WordPress uses the "action" variable to handle many login and logout functions. By default this plugin can handle the normal ones but some plugins and themes may utilize a custom action (such as logging out of a private post). If you need a custom action please enter it here.
Что там писать?
Наталья, приветствую тебя. Рад видеть!
The admin user still exists - это значит, что существует пользователь с логином admin. Везде и всюду рекомендуется не использовать этот логин, т.к. это упрощает подбор пароля. Так что, обязательно нужно сменить.
Что касается кучи настроек, я поэтому в статье и рекомендую начинать не со страницы Dashboard и кнопок Fix It, а проводить все настройки вручную, по пунктам. То есть сразу переходить на вкладку Settings (а затем и на Advanced) и там все настраивать, по порядку, как в данной инструкции.
Конкретно логин admin меняется на вкладке Advanced в блоке Admin User. Там всего три блока (не считая Welcome). Change Content Directory ни в коем случае не трогать, иначе сайт слетит. А вот префикс таблиц БД желательно сменить с дефолтного на какой-нибудь другой, произвольный.
В любом случае, перед всеми манипуляциями необходимо сделать свежий бэкап БД.
Нет, я вижу кнопку, синяя такая "Scan Next File Chunk".
Вообще, с момента публикации данной статьи плагин уже много раз обновился, и вполне логично, что некоторые пункты, какие-то менюшки, какие-то названия и проч. могли измениться, быть удалены или, наоборот, добавлены. Но в основном все по мелочи. Общие настройки, описанные в статье, полностью актуальны.
В абсолютном большинстве случаев - ничего. Так и оставляем пустое поле.
Если что-то останется не понятным, не стесняйся, спрашивай ;) Всегда рад помочь.
Потрясающая инструкция! Целый научный труд и все четко и ясно! Спасибо преогромное! Добавила в закладки, если что! Еще раз благодарю!
Здравствуйте, Марина. Большое спасибо вам за отзыв. Рад стараться.
Всем привет! Скажите, у меня стоит галка возле-Allow iThemes Security to write to wp-config.php and .htaccess., но в high-.htaccess File is Writable: No.
wp-config.php File is Writable: Yes
Интересно, что же он не запретил запись в config тогда ??
И еще такой вопрос: вот уже несколько последних раз, при попытке войти в админку, набираю пароль правильно, и первый раз обязательно ошибка,а со второго раза-нормально заход, и так постоянно уже недели 2...???
Привет! По первому вопросу точно подсказать не могу. У меня на оба файла запрещена запись. И делал я это вручную (выставлял права). Но при этом для плагина запись разрешена. Попробуй также вручную права поставить и проверить, работает ли корректно плагин.
По второму вопросу. Такое наблюдается у многих, но с чем это связано, неизвестно. У меня было тоже самое одно время. Потом этот баг исчез после очередного обновления плагина.
Александр, привет!
У меня возникла такая проблема с плагином. Время от времени мне приходится, менять файл htaccess, если плагин меня не пускает в админ-панель.
Недавно обнаружил, что плагин заменяет мой код из файла htaccess на стандартный для WordPress. Где-то сутки держится измененный код, а потом меняется на стандартный. Также возможно, что изменения происходят при обновлении плагина (это предположение).
Не подскажешь, как мне можно будет изменять файл htaccess, чтобы плагин потом не трогал мои изменения в этом файле. Одна из причин - с измененным файлом мой сайт работает быстрее.
Василий, привет. Даже и не знаю в чем может заключаться проблема. Попробуй после того, как пропишешь нужные тебе правила, поставить права на .htaccess 444. Только в настройках плагина обязательно разреши ему права на запись. Может такая схема поможет. Первое время, если сделаешь так и это сработает, не забывай периодически проверять файл. Ну, и еще активируй (если этого не сделано) File Change Detection, тогда сможешь оперативно узнать, если .htaccess вдруг изменится.
Сейчас там права 644. А я смогу сам изменять файл с правами 444, в случае чего? Честно, говоря я права никогда не изменял. Если нужно, то скачивал файл, изменял его, а потом закачивал. Чаще это делал через файловый менеджер хостинга.
Да, конечно. Ты, как владелец, сможешь изменять его прямо на хостинге.
Александр, Вы проделали титанический труд, написав эту статью!
Примите мои восхищение и искреннюю благодарность. :)
Настраиваю плагин, согласно Вашим рекомендациям.
Вот, в процессе, возник вопрос:
у меня стоят следующие плагины защиты:
Wordpress Firewall 2, Anti-XSS attack, Semisecure Login Reimagined, Antivirus, Antispam Bee и DelRevision (хотя последний, по-моему, к защите не относится, но - на всякий случай :).
Какие из них теперь нужно удалить?
Полина, большое спасибо за оценку статьи. Очень приятно)
По плагинам:
Александр, спасибо большое Вам за развёрнутый ответ! :)
Настроила плагин, который рассматривается в этой статье, и удалила те, что Вы рекомендуете.
Semisecure Login Reimagined - пока, деактивировала. Понаблюдаю...
Но, вот, обнаружилась проблема!
Когда я попыталась установить новый плагин, ввела его название в поиск и нажала на "Поиск плагинов", то открылась страница с такой вот надписью:
"Forbidden
You don't have permission to access /wp-admin/plugin-install.php on this server".
Такая же надпись появлялась, когда я пыталась очистить разом всю корзину комментариев. Подумала, что это случайный глюк.
Ан, нет!
Помогите, пожалуйста, разобраться, в чём причина.
Проблема появилась сразу после установки и настройки iThemes Security... :(
Подобные проблемы наблюдаются достаточно часто. По какой-то причине (со стороны невозможно сказать по какой точно) плагин вас видимо блокирует. Частично проблему можно исправить так - в панели настройки плагина есть самый первый пункт - Don`t Lock Yourself Out. Там нужно нажать на синюю кнопку "Temporarily что-то там..", т.е. временно внести ваш IP-адрес в белый список. Данное действие будет действовать ровно сутки, по истечение которых можно это процедуру продлить еще на сутки. Но правильней, конечно, найти причину того, почему именно плагин вас блокирует.
Кроме того, где-то здесь в комментариях я уже писал, как посмотреть в базе данных, заблокированы вы (может плагин блокирует не вас, а какие-то действия) или нет, и если да, то как снять блокировку все через ту же базу данных.
Александр, в том то и дело, что эта кнопка: "Temporarily Witelist my IP" - была вчера нажата ДО обнаружения проблемы, т. е. мой Ip был в witelist.
Также, мой ip добавлен в Wite list на вкладке Global Settings.
А вот по поводу БД, к сожалению, я не настолько сильна, чтобы залезть туда и что-то там настраивать.
Я, если честно, даже не знаю, где находится эта БД...
Проблема остаётся, и довольно неприятная. :(
Возможно, кто-то столкнётся и найдёт ответ?
Скорее всего проблема не столько в самом плагине, сколько в конфликте с веб-сервером. В общем, попробуйте сначала следующее (в настройках плагина):
Сомневаюсь, конечно, что это поможет, но попробовать стоит.
Дальше нужно выяснить следующее:
После чего отпишитесь по результатам. Будем думать дальше =)
Александр, а Вам - отдельное спасибо за столь серьёзный подход к моему вопросу!
Очень мне это нравится, а ведь мне ещё многому нужно научиться.
Буду изучать Ваш блог! :)
Не за что, Полина =)
Кстати, у вас сайт очень стильно сделан. Мне понравился
Да, Дмитрий, я тоже буду ждать Вашу статью.
Поделитесь, пожалуйста, на неё ссылкой здесь, если Вам не сложно, и если автор этого блога не возражает.
Хочу узнать об рассматриваемом плагине побольше.
Уж очень круто наворочен... :)
Конечно же я не против. Но я бы вам посоветовал еще и подписаться на обновления блога Дмитрия. У него всегда интересные разносторонние статьи, и все по делу.
Александр, спасибо за комплимент стилю моего сайта.
Я очень старалась!
Теперь, вот, озабочена его техническим обеспечением, СЕО и иже с ними. :)
А на обновления блога Дмитрия, по Вашему совету, - подпишусь.
Вот, дождусь здесь ссылку на его новую статью.
А на Ваши – уже подписалась! :)
Можете не дожидаться, а подписаться сразу. Не пожалеете =) Адрес его блога у него в имени указан (ideafox.ru).
Полина, зайдите в настройку settings плагина, промотайте страницу вниз и снимите настройку напротив "non english charactets"
Это должно помочь.
Дмитрий, помог Ваш совет! Ура! :)))
Спасибо большое!
Блин, точно же))) Я все время про эту опцию забываю))
Дим, спасибо!
пож-та) Мой второй блог подвергся ночью очень мощной атаке - еле отбился. Как раз пишу статью. Если бы не этот плагин - грохнули бы сайт.
Ждем статью! Это будет интересно
Да, большое вам спасибо за рекомендацию WP-Optimize!
Найду, изучу и поставлю.
А у Вас, случаем, нет статьи об установке и настройке этого плагина?
Очень уж мне понравился Ваш системный способ изложения материала! :)
Полина, в WP-Optimize собственно особых настроек и нет. Разберетесь без труда.
Василий, благодарю за дополнение. Я, кстати, как раз на твою статью хотел сослаться, зная, что она у тебя есть =) Оставь, пожалуйста, ссылку на нее здесь. И Полине поможет ознакомиться с плагином, и другим может тоже. Хотя ты прав, там особых настроек то и нет (но это не умаляет его достоинств), да и плагин русифицирован.
Да, Василий, оставьте, пожалуйста, ссылку!
Как очень молодому блогеру, мне очень нужны простые пошаговые руководства.
Иначе, легко могу напортачить!
Пожалуйста. :)
Вот ссылка на статью Василия: http://vellisa.ru/plagin-wp-optimize-optimiziruem-bazu-dannyih-vashego-sayta
Александр, большое Вам спасибо за ссылку на статью!
Это будет следующий плагин, который я поставлю. :)
WP-Optimize очень простой в освоении плагин
Здравствуйте! Вот только вчера общались с Вашими читателями, Александром Викторовичем и Василием по поводу этого плагина, они предупредили, что он коварный и дали ссылку на Вашу статью. Плагин у меня стоит где-то с марта и проблем не было, а сегодня захожу, а у меня в почте 10 сообщений о том, что было много попыток войти и поэтому логин админ заблокирован. Меня тоже не пускает, попробовала уже несколько раз, больше пробовать боюсь. По письму, которое Вы опубликовали в комментариях, у меня не получилось, не смогла найти такую таблицу.
Проблема еще и в том, что мне этот плагин ставила и настраивала фрилансер, а я сама с ним еще не разбиралась даже.
Вот сижу сейчас, думаю, что делать. Не подскажете? Может быть можно как-то изменить логин с хостинга?
Здравствуйте, Галина. Мне немножко непонятны некоторые моменты. Вам пришли письма, что такой-то IP-адрес был заблокирован из-за большого кол-ва неудачных попыток входа в админку. Так? В этих письмах указан ваш IP-адрес? У вас админка скрыта этим плагином? И ваш логин случайно не admin?
Кажется, нашла нужную таблицу в базе данных! Но там есть только время атак и нет никаких адресов и имен! Просто удалить все строчки? Или удалить только последние, которые я знаю, (или предполагаю), что это была я? Боюсь удалить что-нибудь не то...
Посмотрите в столбце lockout_host, там должны быть IP-адреса вида 123.123.123.123. Найдите ваш, и удалите эту строку. Или вообще удалите все строки именно в этой таблице (xxxx_itsec_lockouts) /где xxxx - это ваш префикс/
Александр, вы тут про логи говорили. Посмотрел я у себя, а у меня во вкладке "Logs" вообще нет пункта "File Change History" и соответственно никаких журналов логов. Раньше все это было, там я никак их настроек не изменял.
В папке uploads логи есть - 10 МБ. Сейчас так у всех?
Не, Василий, у меня все в логах есть (в выпадающем меню). Проверь, включена ли у тебя вообще опция "Enable File Change detection". И еще в Global Settings проверь опцию "Log Type" - может у тебя там только "Database Only"
У меня в "Log Type" включено "File Only". А опция "Enable File Change detection" включена.
Ну, я тогда не знаю. Попробуй включить в лог тайп оба типа (Both). По крайней мере у меня так. И еще, ты обновился до 4.2.15? Там как раз какие-то баги пофиксены, связанные с логами и file change.
Да, обновился. Ладно, это не очень актуально. Я знаю, где их найти на сайте.
Все равно я на логи не смотрю. Просто обратил внимание, что они перестали появляться. Наверное, настройки пункта "Log Type" я все-таки изменил.
Василий, сделай тогда отправку изменений файлов на почту. Чтобы быть в курсе, на всякий случай
Я это сделал, на почту отчеты приходят.
Большего и не нужно на мой взгляд. Так вполне удобно =)
Установила плагин. Настроила - большое спасибо Вам и низкий поклон!
Но проблем не убавилось. С вашего разрешения, я Вас ими теперь помучаю.
Но всё по-порядку.
Срочно нужно перевести слова в новом шаблоне. Поставила плагин CodeStyling Localization., но он краснеет и ругается, потому что iThemes Security, как я поняла, не разрешает работать CodeStyling Localization. Что и где мне нужно отключить в iThemes Security, чтобы перевести англ. фразы на сайте, и потом отключить плагин CodeStyling Localization?
Спасибо за статью и надеюсь на помощь.
Добрый день, Ольга!
Попробовал я установить этот плагин. Действительно, он выдает предупреждение. Но это не какая-то фатальная ошибка, а лишь предупреждение о возможном конфликте. Сам плагин при этом вроде как работает. Так что, попробуйте перевести то, что вам нужно, несмотря на предупреждение. Если же не будет получаться, можно на время перевода деактивировать iThemes Security.
Могу посоветовать еще один, альтернативный, вариант =) Это миниатюрная программка Poedit (http://poedit.net/). Она по сути занимается тем же: позволяет переводить темы, плагины и т.д. на основе файлов локализации. Возможно такой вариант покажется менее удобным, чем через плагин, но так, на всякий случай, стоит иметь в виду.
Большое спасибо за ответ!
Этот "переводчик" не хочет у меня переводить Темы, а только плагины. Попробую, предложенную вами, программку.
Рад помочь.
Если перевод много времени у вас не займет, то просто отключите на время iThemes Security - это, мне кажется, самый простой выход из ситуации.
А я по неопытности переименовала папку вп-контент. На моем сайте 20 статей пока. Итог - админка работает почему-то только пи отключенном плагине ВП Супер Кэш. Пыталась его удалить не получилось ошибка вылетает. Так и работаю с отключенным плагином кеширования. Эх раньше ваша статья не попалась жаль... Сайт вроде живой. Но в логах пишет что реферер гугл ру ищет папку вп-контент/название картинки и не находит, она ж переименована у меня. Что мне делать теперь? Напортачила вот и растерялась.
да нет картинки все исчезли(((( хотя путь к ним вроде правильный. Не знаю что и делать. Мож все снести и заново сайт сделать?))
Мария, попробуйте обратно переименовать папку в wp-content, только делать это нужно аккуратно =)
1) Сделайте полный бэкап сайта, на всякий случай.
2) Вручную переименуйте директорию (папку) в wp-content
3) В файле wp-config.php (он лежит в корне сайта) нужно найти что-то вроде этого:
И изменить "ваше_новое_название_wp-content" на стандартный wp-content. Если я не ошибаюсь, то можно вообще удалить эти две строки, но точно не помню, поэкспериментируйте.
После данных манипуляций все должно вернуться в первозданное состояние, до смены директории wp-content.
Еще раз напомню - предварительно сделайте бэкап. И запоминайте все действия, которые делаете. Собственно, сложного тут ничего нет.
Обязательно отпишитесь по результату, если вас не затруднит.
PS: Смена wp-content не очень привлекательная процедура, на самом деле. При ней могут не работать некоторые плагины, как в вашем случае, т.к. они бывают жестко привязаны именно к wp-content. Решение найти, конечно, можно (нужно править WP_CONTENT_DIR и все в таком духе), но это лишние мороки.
PPS: Когда будете менять настройки, а затем проверять, работает ли сайт, то обновляйте страницу в браузере, минуя кэш. Это делается комбинацией клавиш CTRL и F5. Иначе страница может загрузиться из кэша, и может показаться, что все работает, а на самом деле это не так, и сайт лежит =)
Да я уже пробовала вручную переименовывать и вп конфиг правила. Знаете что получается? Админка становится на английском... Я за год так наэкспериментировалась с сайтом что туши свет. А уж этот плагин кеширования ваще труба столько файлов создает нужных и ненужных. Я думаю принять решение вообще сайт снести заново Вордпресс поставить и минимум плагинов тогда все чистенько будет с полного нуля. Не думаю что это плохое решение я еще недалеко ушла по статьям.
Мария, я прям сейчас попробовал на тестовом сайте:
1) Сменил wp-content на другое название
2) Затем поменял обратно, вручную. На этом этапе да, админка становится на английском, деактивируются все плагины. Но оно и понятно, т.к. в wp-config прописаны другие абсолютные пути.
3) Исправил абс.пути в wp-config. Все заработало, только плагины пришлось все активировать вручную.
4) Удалил из wp-config те строки с абс.путями - также все работает. Вообще, этих строк там изначально нету (до смены wp-content через плагин), поэтому неудивительно, что их удаление не мешает нормальной работе.
Так что попробуйте еще раз. Должно же сработать.
Примечание: т.к. сайт был тестовый, на нем очень мало плагинов и всего 3 тестовых статьи. Но я не думаю, что это как-то особо влияет.
Здравствуйте,
у меня проблема с [Hide Login Area] Скрытие страницы входа в админку сайта.
Настраивал все по инструкции. Изменил путь к админке и не могу в нее попасть, загружается главная страница сайта. Отключаю этот параметр и захожу по обычному адресу без проблем.
Я переустанавливал сайт и сразу изменил префикс wp_ и название БД.
Ранее на сайте (когда все было стандартно) Hide Login Area работал корректно и при смене адреса всегда загружал вход в админпанель.
Подскажите, пожалуйста, где проблема?
Доброго времени суток.
Сложно сказать точно, но симптомы несколько похожи на срабатывание Away Mode, т.к. именно при этом режиме происходит редирект на главную. Попробуйте скорректировать в настройках время активации Away Mode, или полностью его отключите.
Также попробуйте поиграться с прочими настройками Hide Login, а именно с Enable Theme Compatibility (отключить или наоборот включить ее).
Ну и есть еще "подлая" функция у плагина - Filter Non-English Characters - попробуйте и ее отключить. Хотя когда она срабатывает, там приходит ответ с ошибкой 403, а не редирект на главную.
Больше даже и не знаю в чем может быть причина. Если все это не поможет, пробуйте экспериментальным путем (методом тыка) - отключайте поочередно различные настройки, пробуйте. Но мне все-таки кажется, что это срабатывание Away Mode, т.к. симптоматика такая же.
Если вас не затруднит, то отпишитесь, пожалуйста, по результатам.
Away Mode я вообще не включал, нет надобности.
Filter Non-English Characters не использовал т.к. читал о возможных проблемах.
Enable Theme Compatibility - включение и отключение не помогает.
Странно и другое, Back Up'ы на почту не приходят.
Причина найдена:) у меня была включена "заглушка" плагин ThemeFuse Maintenance Mode. Только я его отключил все заработало. Нужно не забывать отключать Hide Login Area при включенной "заглушке", иначе в админку не попадешь. Но Back Up'ы на почту не приходят.
Спасибо за ответ. Теперь будем знать о конфликте с плагином ThemeFuse Maintenance Mode, и, возможно, с другими аналогичными.
По бэкапам. Раньше все отправлялось? Или изначально так и было?
Для начала попробуйте на вкладке "Backups" нажать на ручное создание рез.копии (Create Database Backup), и посмотрите вверху уведомление, что там будет написано. Если все ОК, пишется "Backup Completed and emailed to backup recipients", если имеется проблема, то будет "Something went wrong with your backup. It looks like another process might already be trying to backup your database. Please try again in a few minutes. If the problem persists please contact support", или вообще произойдет переадресация на пустую страницу с надписью "Security Error". Таким образом можно выяснить, куда копать дальше.
Кстати, у вас для отправки e-mail от плагина какая почта используется? Доменная? Каков объем БД? Доменная почта обычно весьма урезанная, по сравнению с публичной, типа gmail. В общем, стоит на это тоже внимание обратить.
Также стоит проверить на хостинге наличие директории /wp-content/uploads/ithemes-security/backups и какие права установлены у каталога backups. Если такого каталога вообще нет, то его нужно создать вручную. Права на него должны быть 750.
Еще часто бывает такое, что процесс создания бэкапов занят каким-то другим плагином. Так что, если есть подобные решения, можно попробовать их отключить.
Ну, и последнее, нужно проверить все настройки плагина, которые затрагивают бэкапы - в Global Settings (указан ли Backup Delivery Email), ну и в Backups все еще раз перепроверить, все ли галочки отмечены, все ли опции включены.
Более вероятной мне видится проблема с директорией backups (или ее отсутствие, или некорректные права). Но не факт, конечно же. Может и конфликт с темой или каким-нибудь плагином.
P.S. Попрошу также отписаться по результатами, если не затруднит. В пору на основе всех проблем с плагином создавать целый большой FAQ с возможными решениями оных =)
В секции Global Setting появился пункт (последний) Disable File Locking. Как настраивать его?
Плагин предлагает изменить имя директории "wp-content". Я побаиваюсь это делать, что посоветуете (сайт с нуля пустой)?
Также требует Change Table Prefix. Но я при установке WP уже менял имя БД.
Disable File Locking - честно сказать я так и не понял, какую именно опцию этот пункт затрагивает. Но там написано, что лучше ничего не менять.
Менять директорию wp-content не стоит. Это может "убить сайт" (не насовсем, конечно же) и вызвать в будущем массу лишних проблем - нужна будет правка абсолютных путей в некоторых плагинах и проч.
Change Table Prefix - если префикс таблиц уже меняли, то не стоит обращать внимание на данное уведомление.
А я создала сайт с нуля и все-таки поменяла эту папку вп-контент вручную. Погуглила, там надо код определенный в вп-конфиг вставлять. Работаю дальше над рекомендациями плагина по безопасности.
Мария, лучше все-таки не менять название директории wp-content, т.к. в будущем могут возникнуть трудности. Вы же в этом уже убедились =)
Наверное вы правы. Второго сноса сайта я не переживу. Во избежании будущих проблем переименую обратно. Думаю плагин итак достаточно защищает мой труд, чтобы я могла спать спокойно...
Думаю это будет правильным решением. Сама по себе смена названия директории защищает лишь от всяких ботов, которые ищут уязвимости. Но с ними плагин и без того справляется на ура. А вот если сайт захотят "хакнуть" целенаправленно, то смена директории совершенно ничего не даст. Поэтому не стоит создавать себе лишнюю головную боль =)
С BackUp'ом ничего не получается. На почту (принудительно отправил и получил подтверждение от плагина) файлы не приходят и на диске в папке пусто. Странно, на старом сайте все прекрасно работало (шаблон тот же). На денвере ( копии сайта) тоже самое.
Вы права на папку backups проверили? Если все с ними, как надо, то я даже и не знаю, в чем может быть причина. В бесплатном саппорте (http://wordpress.org/support/plugin/better-wp-security) почитал - ничего кроме того, что я уже выше изложил, так и не нашел =(
Ps. я страницу поддержки плагина на wordpress.org периодически просматриваю, возможно у кого-то появится похожая проблема и будет найдено решение. А пока, увы.
Отличная статья, полезный плагин, автору респект!
В бекапе только почему-то не работает путь, отличный от дефолтного - все равно в ту же папку кидает копии базы данных. Но это все мелочи )
Сергей, спасибо.
Насчет пути даже и не знаю. Никогда не пробовал его менять. Да и не вижу смысла хранить бэкапы там же, где и сам сайт
Александр , здравствуйте. Плагин очень нравится.Сегодня после обновления плагина в настройках появилась опять красный пункт.Требуется активация IP ключа для сканирования. Насколько критично для работы плагина, если не активировать эту функцию?
Добрый вечер. Да, недавно в плагине появилась новая интересная функция - сканирование сайта на "вирусы" (на вредоносные объекты). Чтобы ее активировать, нужно зарегистрироваться на сайте virustotal.com и получить API-ключ (все это бесплатно и без каких-либо трудностей - самая обычная регистрация). Затем полученный ключ вписать в специальное поле в плагине.
Активировать ли эту функцию? А почему бы и нет! Само сканирование запускается только в ручном режиме (на вкладке Settings). Сайт проверяется сразу несколькими антивирусами. В принципе, все тоже самое можно сделать на самом сайте virustotal.com безо всяких регистраций.
В общем, решать вам - активировать данную опцию или нет.
А я не знал, что добавили проверку на вирусы. Зарегистрировался.
Александр, не подскажешь, должна ли быть изменена в настройках плагина такая запись:
wp-config.php File is Writable: Yes
Если да, то как это сделать практически?
Лучше, чтобы wp-config был не доступен для записи. Для этого достаточно выставить на него права 444.
В разделе Brute Force Protection появился новый пункт
Automatically ban "admin" user
Стоит ли его активировать?
Да, лучше активировать. Будет меньше дополнительной работы для плагина и попыток "взлома". Если, конечно, вы сами не используете такой логин =)
Привет, Саш. Прости за оффтоп. http://ru.giveawayoftheday.com/site-visualizer-pro-1-5/ Не заходил?
Привет! Заходил, скачал, установил =)
Я на этот сайт подписался, чтобы интересное не пропускать.
Привет Александр! Есть вопрос по плагину, а точнее по логу ошибок. У меня было много ошибок 404. Несколько удаленных статей (типа "Привет мир") Потом менял АДМИНА на нормальный логин, это сказалось на адресах. Они где то болтаются в сети и дают эту ошибку.
Не так давно, по рекомендации знакомой, сделал редирект. В страницу 404 вставил не большой код и все ошибки (если в адресе страницы после домена набрать любую абракадабру) перебрасываются на главную страницу моего сайта. Ошибка 404 пропала.
Теперь плагин в логе ошибок пишет об изменении файлов, не пойму что это значит? Кто меняет эти файлы?
Привет!
Мониторинг изменения файлов - это функция плагина. В принципе, ее можно отключить, чтобы лишних вопросов не возникало. В частности для менее опытных пользователей так и рекомендуется. Но данная опция может очень здорово помочь, если вдруг обнаружится, что кто-то взломал сайт или нашел лазейку и внедрил какой-то код, или загрузил вредоносные файлы, и т.д.
Из легальных действий изменение/добавление/удаление файлов происходит по нескольким причинам:
1) Удаление/обновление/установка тем и плагинов - вполне логично, что файлы на сервере при этом изменяются =) тоже самое, если движок будет обновляться. Ну тут в общем все понятно.
2) Кэш - он меняется постоянно (если имеется плагин кэширования), и из-за этого в мониторинге изменения файлов постоянно образуются целые "простыни" - длиннющие списки. Рекомендуется в секции настроек File Change Detection добавить директорию wp-content/cache/ в список исключений.
3) Всякие служебные файлы, логи и т.д. - тут тоже все логично - файлы логов постоянно меняются и плагин фиксирует эти изменения. Известные файлы логов желательно также добавить в список исключений.
4) Плагином также фиксируется внесение изменений в .htaccess (например, когда сам плагин кого-то забанил и внес в этой файл его IP-адрес). За этим пунктом нужно следить особенно тщательно.
Всякие другие действия могут считаться подозрительными. Но еще раз повторюсь: если не хочется заморачиваться и забивать себе этим голову, то данную опцию можно отключить.
Спасибо, понятно. Собственно записей не много, порядка десяти строчек в сутки (он захватывает и сайт магазина, у них там какая то общая папка). В одной строчке говорится о том что БЭКАП выполняется. Остальные все одинаковые, только время отличается. Так что пусть будет, вдруг пригодится.
Я эти логи регулярно удаляю, наверное это правильно?
Раньше нужно было обязательно чистить логи, периодически. Т.к. они могли занимать много места. Сейчас это делать не обязательно, т.к. при достижении размера 10 Мб для логов, место больше не занимается, а начинают перезаписываться наиболее старые записи. Короче говоря, больше 10 Мб логи не смогут занимать. Но можно и руками периодически удалять.
Вот об этом ограничении занимаемого места я не знал. Удаляю просто нажатием на кнопку внизу. Так бегло глянул, там всегда одно и тоже. Если вдруг вижу что то новенькое, пытаюсь перевести переводчиком, сам я в Английском круглый двоечник.
Александр, ты все делаешь правильно!
Посоветуйте плагин для Backup'a (мне так и не удалось заставить iThemes их делать). Спасибо.
P.S. Вижу вам предстоит работа по обновлению статьи. Можно даже сделать FAQ по популярным вопросам.
Повыбирать есть из чего =)
Рекомендуемый в Кодексе WordPress плагин - http://wordpress.org/plugins/wp-db-backup/
Более расширенные и продвинутые плагины:
https://wordpress.org/plugins/backupwordpress/
https://wordpress.org/plugins/backup-scheduler/
https://wordpress.org/plugins/ready-backup/
и так далее. Пробуйте, тестируйте, выбирайте.
P.S. Была такая мысль, чтобы дополнять статью, но я от нее отказался. Плагин постоянно обновляется, добавляются новые функции.. Так статья может перерасти в размер книги =) Насчет FAQ-а тоже думал, возможно сделаю отдельную статью-FAQ.
Help me please:)
Установила, активировала плагин. В первых четырех блоках изменения настроек сохранились нормально. А вот начиная с Brute Force Protection и дальше, не сохраняется. Кнопка нажимается, но ничего не происходит. При обновлении страницы все несохраненные настройки слетают в первоначальное положение. :( Плагинов активированно по минимуму, вроде бы конфликтовать не с чем. Не подскажете, в чем может быть проблема?
Карина, добрый день.
К сожалению, слышу про такое впервые, поэтому помочь не могу. Могу лишь посоветовать одно - деактивировать, удалить и заново установить плагин. Иногда это помогает.
Пробовала удалить и переставить по новой, не помогло. Причем одна и та же проблема на всех сайтах на этом хостинге: не сохраняются настройки. У меня такое подозрение, что дело в каком-нить расширении.
http://savepic.org/6018695.htm
Александр, если не сложно.. А вы не можете сравнить со своими настройками? чего же ему не хватает...
Ну, если на всех сайтах хостинга одно и то же, то вероятно в этом и причина. Но я, к сожалению, помочь не смогу. Не силен я в этих вопросах. Лучше сразу к хостеру обратиться.
Насчет расширений PHP, ну для начала попробуйте JSON включить. Потом поочередно остальные расширения. Может быть найдете недостающее звено
P.S. Все расширения, что у вас не включены, на моем хостинге активированы.
Александр, после обновления плагина, появилась, как я понял, новая возможность получать информацию от iThemes Brute Force Network Protection. Поясни, что нужно делать?
Привет, Василий!
Да там все просто - нужно ввести свое мыло в поле "Get your iThemes Brute Force Protection API Key" и сохранить настройки. На мыло придет API-ключ, затем его ввести в тоже самое поле.
На другом блоге у меня как-то по-другому все получилось: ввел мыло, сохранился, на мыло пришло письмо с инструкцией, но не сам ключ, ввел мыло еще раз, сохранился, и в этом поле автоматически прописался API-ключ (и одновременно с этим пришел на почту).
Кстати, Brute Force Network Protection - отличная штука.
Спасибо за статью, буду изучать в несколько заходов.
На мой сайт постоянно идут попытки взлома, каждый час. Так меня оповещает плагин Wordfence.
Один вопрос. Не будут ли конфликтовать эти два плагина?
Здравствуйте, Алексей.
По идее не должны конфликтовать. Но желательно исключить повторяющиеся функции, если они будут.
Сегодня также столкнулся с надписью в плагинах New! Take your site security to the next level by activating iThemes Brute Force Network Protection.
Спасибо за расшифровка и ценную информацию в заметке.
Меня также пару раз данный плагин в админку не пускал с правильным паролем.
Пришлось мне зайти на хостинг и перезаписать пароль для своего логина, он почему то был изменен. Я до сих пор эту загадку не разгадал, прямо полтергейст какой-то.
Сначала я грешил на плагин Login Lock Down, затем его удалил, но история повторилась вновь.
Приветствую, Николай!
А когда плагин вас не пускал, вы пробовали второй раз ввести логин/пароль? У него есть такой глюк - периодически не пускает с правильными учетными данными. Но после того, как данные ввести повторно, становится все ОК. Очень странный глюк =)
Login Lock Down действительно не нужен, т.к. iThemes Security умеет делать тоже самое.
Кстати, ещё один нюанс - после включения в iThemes опции автоматического бэкапа, у меня в корневой директории вордпресса, сами по себе стали появляться в большом количестве файлы «core», удаление которых ни к чему не приводило, т.к. они сразу-же появлялись по новой. размер каждого файла примерно 160Mb. Лимит дискового пространства забивался в течение 1-2 дней.. Судя по всему, здесь имеет место конфликт с каким-то из плагинов, т.к. на двух других сайтах, находящихся на этом-же хостинге, таких проблем не возникало.
Вот как это выглядит: http://i64.fastpic.ru/big/2014/0916/8c/b272371b5da199edb96c8b58ffbf2c8c.png
Ого, вот это жесть!
Впервые про это слышу. Буду иметь в виду.
Как решили проблему? Просто не используете автобэкапы?
Александр , здравствуйте. после обновления появился пользователь с идентификатором 1. При попытке его удаления , не удаляется.Сейчас проверила еще сайт. Ситуация точно такая же.
У меня точно также. Я пока не знаю, как с этим бороться.
Предлагаю ничего не предпринимать и подождать очередное обновление =)
Александр, добрый вечер. У меня наконец обновился плагин. И пользователь с идентификатором 1 исчез. Я собираюсь менять шаблон сайта. Как вы думаете плагин в этот момент лучше отключить?
Значит, как и предполагалось, это был глюк.
Насчет обновления шаблона - лично я обновлялся и не отключал его, и все всегда было нормально.. Хотя все же рекомендуется временно отключать подобные плагины и плагины кэширования на время обновления.
По поводу плагина кеширования. Я еще не ставила его.Когда его надо ставить?
На мой взгляд плагин для кэширования нужно ставить после полной настройки WordPress, установки и настройки всех основных плагинов. В общем, когда сайт полностью готов, тогда и следует задуматься о кэшировании.
Кто-то говорит, что пока посещаемость невелика, можно не ставить. Но как по мне, так пусть кэширование работает сразу. Это и снижение нагрузки на сервер, и увеличение скорости загрузки сайта для пользователей.
Видимо это не было глюком. Сегодня в твиттере попалась ссылка. Посмотри. Это как раз тогда, когда было предпоследнее обновление. Наверное вся ситуация была связанна именно с этим.
Нет. Там другое. У них сервер хакнули с базой данных клиентов.
Самое смешное, что они в том числе и безопасники, а хранили пароли в базе в незашифрованном виде. Ужас. Cory Miller писал, что пароли у них так хранятся с 2009 года, и типа все никак не успевали это изменить. И типа раз уж они теперь взялись за iThemes Security, и Кори к ним пришел, то будут все менять, переделывать и т.д.
Но даже если бы у них не было Кори и этого плагина, они ведь все равно предоставляли вполне серьезные сервисы - бэкапы, синхронизация и прочее. Как можно было так беспечно к этому относиться, у меня в голове просто не укладывается.
А глюк с id 1 - это все-таки глюк (ну, точнее баг).
Добрый день, Александр.
Не первый раз решил воспользоваться данным плагином, до этого все было великолепно, благодаря Вашей инструкции в том числе.
А сейчас возникла проблема: установил плагин на локальный сайт, активировал, все нормально работало. Настраивать не стал. После переноса сайта на хостинг войти в админку не смог, отображает просто белую пустую страницу. Удалил плагин через FTP, установил заново, при активации опять открывает только белую пустую страницу. Не подскажете куда копать?
Сергей, первым делом отключите настройку Non-english characters в разделе system tweaks. Если не поможет, пробуйте поочередно отключать настройки плагина.
Как только активирую плагин, я вообще не могу зайти в админку. Но кажется я нашел решение. Включил debug в wp-config и увидел ошибку которую выдает - не хватает памяти. Буду менять тарифный план на хостинге, надеюсь проблема исчезнет.
Да, debug-режим часто выручает
SOS!!! Я устанавливала по вашей статье на основном сайте плагин, дошла до настроек Бана Юзеров и т.п., нажала "сохранить" и вылетела из админки, теперь при попытке ввести строку site.ru/wp-admin/ меня кидает на главную! Что делать и что я сделала не так? Посмотрела в PHP Admine моего айпи там нет
Какая же хорошая привычка читать комменты, пусть и не нашла решение своей проблемы, но по крайней мере зашла на сайт. Сделала, как Сергей написал: "И у меня такое случилось на одном из сайтов. Может быть кому то поможет. Сделал вот что.
1. зашел через FTP и переименовал папку плагина на Better-WP-Security000
2. после этого уже смог зайти в админку,
3. зашел в плагины, Better WP Security после переименования был деактивированным,
4. было уведомление о новой версии, я обновил, затем активировал его.
И после этого все стало как надо."
Пока не буду активировать плагин, подожду помощи.
Катя, не советую вам ставить оба этих плагина (BPS и iThemes). Ранее да, я где-то тут писал, что можно и оба их использовать, но они с того момента прилично сэволюционировали. И сейчас практически полностью повторят функционал друг друга.
Я бы посоветовал остановиться на ithemes security. Он все же более функциональный.
Что касается проблемы: вы случайно не активировали режим Away Mode? Проверьте. Когда происходит редирект из админки на главную - это похоже на активный режим away mode.
Также на первых порах не включайте фильтрацию по Non-english characters. Т.к. мы тут все не англоязычные, то данная опция часто вызывает трудности. Потом, когда все настроите, можете попробовать ее включить, потестировать, нет ли где конфликтов. Опция сама по себе очень полезная в плане безопасности.
Это да... Часто и в комментариях на блогах бывает много полезной информации
Кстати, вот нашел в камментах несколько похожую проблему: http://bloginfo.biz/ithemes-security-formerly-better-wp-security.html#comment-5918
Может быть у вас тоже стоит какой-то maintenance-плагин? Или заглушка включена в BPS, например?
Спасибо за помощь. Да, я кажется активировала этот режим, получается что не нужно? Хорошо, не буду включать фильтрацию. Я часто много интересного, как раз и полезного, нахожу именно в комментах. Ведь зачастую в статье дается теория, а в обсуждениях, как раз практика.
Нет, такой плагин у меня не стоит, я вообще все, что можно стараюсь без них делать. Но почитать стоит)
Нет, почему же. Его можно включать. Даже полезно. Только нужно четко прописывать время недоступности админки. То есть тот интервал, в который админка точно не будет нужна.
Но даже если вдруг срочно понадобиться админка, а она не доступна по режиму away mode, то и это можно исправить. Вот тут я писал про способ: http://bloginfo.biz/ithemes-security-formerly-better-wp-security.html#comment-5450
Или вы не про away mode, а про non-english characters?
Здравствуйте! Спасибо за статью, очень помогла настроить плагин! Но через некоторое время, при входе в админку, стало появляться сообщение "У вас недостаточно полномочий для доступа к этой странице". Через некоторое время проблема исчезает. Затем снова появляется. Как это исправить?
День добрый, Сергей
Первым делом попробуйте отключить в настройках плагина фильтрацию non-english characters. Вроде как должно помочь.
Спасибо за ответ! Вроде помогло.
И кстати, благодаря этому плагину прекратились попытки взлома админки, которые длились почти сутки. (нагрузка на сервер выросла со стандартных 0-1% до 52%, благодаря этому и заметил неладное)
Точнее попытки продолжались еще около 6 часов, но уже никакой нагрузки не давали, "отшивались" на подходе)
В общем спасибо автору за подробное описание настроек, своими силами не каждый разберется.
Всем советую поставить, отличная штука
Евгений, благодарю, что отписались о решении проблемы и за развернутый комментарий.
Здравствуйте, Александр скажите пож. при смене префикса wp_ в файле robots.txt его тоже надо менять?
Радик, добрый день.
Нет, эти вещи никак не связаны. Смена префикса wp_ - это смена префикса таблиц базы данных. К директориям wp-content, wp-includes и т.д. это не имеет отношения.
Добрый вечер, Александр!
Подскажите, плагин BulletProof Security нужно ставить как дополнение или BWS достаточно?
Здравствуйте.
Нет, в абсолютном большинстве случаев использовать оба плагина нет смысла. Используйте какой-нибудь один.
Спасибо!
Буду "сносить". А то после прочтения этой статьи, с мыслю "а дядька классные советы даёт", пошел выполнять все подходящие рекомендации. Теперь вот лишнее надо убирать)
Просто дело в том, что когда я писал статью про Bulletproof, а также упоминал его и BWS в других статьях и камментах, то они оба были не в том виде, что сейчас. И в принципе отлично друг друга дополняли (если исключить дублирующиеся функции). Сейчас они оба эволюционировали и практически весь функционал (за совсем небольшим исключением) повторяется.
Самый лучший вариант - это использовать iThemes Security, а от BPS взять недостающее (поставить его на какой-нибудь тестовый сайт и посмотреть, что он умеет). Но это уже ручная работа и в целом без особой надобности. Просто я не ищу легких путей никогда =))
Кстати, после удаления BPS обычно нужно вручную БД чистить, иначе там остаются хвосты от него.
Спасибо за ответ Александр, но тут прочитал ваш последний комент. про удаление BPS возник вопрос про хвосты от него.
У меня на сайте стоит именно BPS а на тестовом BWS. Как протестирую BWS поставлю на сайт. А, что за хвосты надо в БД почистить после удаление BPS.
Ну, если решите перейти и откажетесь от BPS, то после его удаления в БД могут остаться пару таблиц вида "префикс_bpspro_блаблабла". Обычно плагины именно такие хвосты и оставляют. Дополнительно можно еще сделать запрос к БД на поиск символов "bps" в других таблицах.
А эти хвосты могут нарушить работу сайта или плагинов на сайте?
Нет, если удалить именно то, что нужно =) В любом случае, перед какими бы-то ни было манипуляциями с БД нужно позаботиться о создании ее свежей резервной копии.
А хвосты чистить нужно. Вот у меня именно с BPS был случай - после удаления: смотрю задания в wp-cron, а там есть ежечасное задание по отправке то ли бэкапов, то ли логов по e-mail, точно уже не помню. Это лишняя нагрузка. А на этом блоге уже давно остались как-то хвосты от плагина DB Cache (точное название не помню), так там в cron было столько заданий (не меньше десятка в секунду), что я на своем хостинге чуть ли не весь сервер ложил из-за такой нагрузки =)) Шучу, конечно, насчет сервера, но нагрузка была колоссальная. Долго мы с саппортом искали причину, но все же нашли - вот эти вот хвосты от некорректно удаленного плагина.
Но даже если плагины и удаляются правильно (деактивировать => удалить), то всякие сопли все равно в базе иногда остаются.
Понятно, спасибо.
Здравствуйте, Александр подскажите пож. а в BPS есть скрытие страницы входа в админку сайта, долго в нём разбирался но так и не нашел эту функцию. Я так понимаю её там нет.
День добрый. В BPS пока такой функции нет.
Всё понятно, спасибо.
Извините, рано панику поднял, удалите комментарий (если не нужен) проблема решилась скрытием админ панели. Старый способ перестал работать, поэтому все это и появилось.
Рад, что разобрались :)
Здравствуйте Александр подскажите пож. там есть ещё настройка ID пользователя. Я настроил её но так и не понял, что произошло. Что эта настройка делает? И для чего она?
Перешел в блог "Dashboard" нашел его в параметре "Завершено" в белом цвете.
Там пишет, что "Пользователь с идентификатором 1 была удалена".
WordpPress по умолчанию присваивает первому пользователю, который как правило, администратор - id=1. Таким образом если в адресной строке написать сайт.ру/?author=1, то откроется страница архива с записями этого пользователя. Причем будет указан его реальный логин, т.е. адрес примет вид сайт.ру/author/реальный_логин.
Собственно, поэтому id=1 желательно менять. Это дополнительная защита от различных нехороших ботов.
Вчера обнаружила бота, который видит мой измененный вход.Меняет IP.
Я и раньше замечала, что такое случается. Как правило одного внесения в бан хватало.Александр, чем это чревато?
При условии стойкого пароля, нетривиального логина и защиты от брутфорса риски сильно минимизируются.
Не тривиальный это как? Он у меня не совпадает с ником. А логин изменить можно?
Хотела спросить по поводу SSL. Я ее ранее не активировала, сайт находился на хостинге, который не поддерживал технологию.Подскажите как ее надо настроить. Мне в статье не совсем понятно.
Нетривиальный - это, как минимум, чтобы этот логин вы вообще нигде больше не использовали. Ни для почты, ни для соцсетей, ни для прочих регистраций. Короче говоря, уникальный. И не admin, root, administrator и т.п. Можно вообще в качестве логина использовать какую-нибудь абракадабру типа yusi999dws_ss3
SSL - это очень обширная тема. В контексте конкретно этого плагина - ничего настраивать не нужно, т.к. для начала нужно купить сертификат и, соответственно, выделенный IP-адрес. Если финансы позволяют, то можете уточнить у своего хостера всю процедуру. Для блогов шифрование особо не нужно, разве что для админки и страницы авторизации, чтобы никто не смог перехватить пароль. Для коммерческих сайтов и, тем более, интернет-магазинов шифрование желательно, а в некоторых случаях обязательно.
И еще у меня когда произошла ситуация с идентификатором 1 перестали приходить бэкапы на почту.
Проблема с бэкапами на почту - весьма актуальная. У меня на одном сайте такая же беда. Никак не могу найти причину.
У меня только на одном нет бэкапов. С другими как-то все ок.
Что самое интересное, у меня аналогично =) Никогда ранее не было с этим проблем, а вот недавно на одном сайте случилось.
Вчера начала искать у себя на сайте. Они оказались в папке 14 экземпляров. Не знаю , что делать . Отключение плагина не помогло. Поставила плагин для бэкапов он тоже не стал отправлять.
То, что бэкапы хранятся локально, это ничего страшного. Просто установите фиксированное кол-во бэкапов для хранения, чтобы дисковое пространство не перерасходовать.
Ну, а с отправкой их по почте, я не знаю что делать, к сожалению. Все перепробовал.
Только, что была на _https://wordpress.org/support/topic/unable-to-run-backups_
Правда не поняла , что надо сделать.Поправь если ,что. Нужно удалить папку бэкапов там , где плагин делает их."/ WP- content / uploads / ithemes- safety / backup "/Сейчас посмотрела все там и находится. А права доступа 750, это где надо смотреть.
А где это устанавливать? У плагина в настройках на почту. Это у плагина так запланирован, если на сервере, то их там 14 экземпляров постоянно. Их больше не становится. Я так понимаю плагин их удаляет.
В настройках плагина в разделе "Database Buckup" посмотрите опцию "Backups to Retain". Там указывается точное кол-во бэкапов, которые будут храниться. 0 - отключить эту возможность.
Если кратко, то там советуют проверить, существуют ли на сервере папка backup и какие права для нее выставлены. Должны быть 750. Если этой папки нет, ее нужно создать вручную и выставить требуемые права. Если папка есть, то советуют ее удалить и создать вручную, с требуемыми правами.
Права меняются через файловый менеджер вашего хостера. Если файлового менеджера на хостинге нет, используйте локальный, типа FileZilla, Total Commander или любой другой.
PS: мне на проблемном сайте это не помогло.
А у меня что то странное творится последнее время, в других браузерах он меня не пускает в админку, когда набираю адрес админки пишет 403 Access denied. Плагин отключать не хочется, очень он мне нравится. Одна надежда на вас.
Татьяна, скорее всего, поможет отключение фильтрации Non-engilsh characters
ps: ваш комментарий почему-то в спам улетел
Здравствуйте. Спасибо за статью, но плагин малость разочаровал. Навороченный, а толку мало. Скрыть вход в админку должным образом не может. Достаточно зарегистрироваться и войти в админку, набрав wp-admin, а там, даже если админ бар плагинами или в настройках отключён, то в админ панели он появится. В нём достаточно подвести курсор к ссылке "Выйти" и слева внизу появится скрытый адрес входа. И никакие плагины редиректа и скрытия бара не помогают. Единственное, я где-то видел код, позволяющий напрочь отсечь панель от зарегистрированных посетителей. Вот он да...действует. А всё остальное ерунда.
Владимир, добрый день! Не совсем понятны ваши требования. Что значит?
Если вы скрываете админку этим плагином, то при входе по wp-admin вы не получите страницу, где нужно ввести логин и пароль, а получите страницу 404. Это и есть скрытие админки. То есть, не зная секретного адреса никто не сможет ни зарегистрироваться, ни войти в админку. Конечно, если вы блок Meta с секретным адресом не оставляете.
Ну, а если вы уже залогинены, то конечно при нажатии на "Выйти" вы увидите секретный адрес. Тут нет ничего удивительного. Вы же (или зарегистрированные пользователи) как-то залогинились, значит от вас (от них) уже не нужно это скрывать.
Тут главное правильно распределить роли зарегистрированным пользователям, или вообще отключить регистрацию.
Кстати, в прежних версиях плагина можно было отдельно делать секретный адрес для админа и для всех остальных. Не знаю зачем убрали.
Ну, а если вам все же хочется вообще убрать этот админ бар для всех, кроме админа, то вот тут почитайте. Отключается буквально парой строчек кода.
Здравствуйте Александр. Спасибо за ответ.
Наверное я неясно изложил.
Предположу, что боты атакуют стандартную страницу авторизации WordPress. Возможно ошибусь, но если после скрытия адреса стандартной страницы, число изоляций многократно снизится, значит так оно и есть.
Отказаться от регистрации не могу, так как посетители у меня в статусе покупателей.
Они, как и я сам, авторизируются на странице созданной плагином магазина.
Надеюсь что настроить программу на взлом такой страницы входа сложней, чем перенастроить её на взлом стандарной по новому адресу.
Регистрация на моём сайте предельно простая и неизвестно кто зарегистрируется следующим - покупатель или хакер, который в первую очередь войдёт в админ-панель и глянет на адрес ссылки "Выйти".
Покупателю админ панель не нужна. Woocommerce так устроена, что все изменения в своём профиле покупатель может выполнять не входя в админ-панель.
За ссылку спасибо, но она удаляет админ-бар, а не админ панель, и то только при просмотре сайта. При заходе же в админ-панель админ-бар появляется.
Владимир, значит я вас не так понял сначала.
Если речь о магазине, то конечно ситуация несколько иная. Тогда я бы вам порекомендовал не пытаться скрывать админку и не париться по этому поводу, это лишнее. Достаточно ее скрыть средствами плагина, точнее даже не скрыть, а заменить (это слово в данном случае уместнее). Это чтобы отсекать всяких автоботов ненужных, ищущих wp-login и wp-admin
Конкретно этот плагин достаточно хорошо защищает админскую часть от брутфорса - банит тех, кто несколько раз неуспешно пытается авторизоваться, причем эту опцию можно настроить на максимально жесткие правила.
Так может быть тогда наоборот воспользоваться этой ссылкой? Если юзер авторизуется, он ведь не переходит автоматически в админку, как обычно бывает в WordPress, а остается во фронтенде (лицевой части сайта).Так ведь? Тогда если скрыть админ-бар, никто из рядовых покупателей и думать-знать не будет про какую-то там админку. Ну, а то что при нажатии на "Выход" страница палится, пусть так и остается. Я лично не знаю, что тут можно придумать. Это нужно к PHP-шникам обращаться, или веб-админам (возможно это можно сделать на уровне веб-сервера, но не уверен).
Добрый день Александр. Можно вопрос не совсем по плагину, но по теме SSL. Хостинг предлагает сертификат SSL по акции за 999 рублей - это нормальная цена? Я не когда с этим не сталкивался. Есть желание использовать для сайта магазина.
Приветствую! 999 рублей - хорошая цена. У хостеров обычно дороже. А у тебя в магазине регистрация, оплата и т.п. идет через твой сайт, или покупателей перекидывает на головной магазин? Если перебрасывает, то тебе и не к чему тратиться на сертификат, я считаю. Хотя можно и приобрести для защиты от перехвата пароля, когда ты сам логинишься в админке.
Кстати, помимо самого сертификата нужно будет оплачивать еще и выделенный IP-адрес. И уточни обязательно, что именно это за сертификат и какой удостоверяющий центр его выдает (напр., Comodo, Thawte и т.д.). Хотя скорее всего это будет Thawte SSL123. Этого сертификата будет достаточно.
У меня покупатель оформляет покупку прямо на моем сайте, без дополнительных переходов. Но регистрация не предусмотрена и не требуется. Просто после нажатия кнопки купить, покупатель должен, ввести свои контактные данные. переговоры ведутся по телефону.
Отзывы оставляются по имени и городу проживания, но идут мне на проверку.
Меня больше волнует панель управления. Оттуда можно изменить некоторые настройки магазина. Логин и пароль у меня хорошие, но ведь вскрыть можно все. А попыток просмотра страницы панели управления много (статистика показывает).
Вот я и думаю, что нужна дополнительная защита входа в панель управления.
В таком случае, SSL будет хорошим плюсом. Кроме того, Google недавно заявил, что будет повышать в выдаче сайты, использующие https.
А админку/панель управления нужно защитить, например, дополнительной авторизацией на уровне веб-сервера. И тогда вообще все в шоколаде будет =)
Здравствуйте! У меня установлен этот плагин. В настройках, в блоке "авторизация" есть такой пункт: "Максимальное количество попыток входа: Установите значение для максимального количества попыток входа, после чего IP-адрес будет заблокирован".
"Ограничение времени попыток авторизации (минуты): 15"
Устанавливаю 5, меняла на самые разные цифры от 2 до 10, ничего не помогает. Почему-то IP-адрес блокируется уже после 1-го не верного ввода пароля. А реальных людей, которые не верно с 1-го раза вводят пароль - куча, а это реальные клиенты. Не хочется их терять.
Как думаете, в чем может быть проблема? Почему IP-адрес блокируется сразу после первой неверной попытки ввода, а не после 5-й как установлено?
Сложно так сразу сказать. А когда пользователь блокируется после первого неудачного ввода пароля, какое действие происходит? Какое сообщение выдается?
PS: только что зарегистрировал у вас тестового пользователя "bebebe", попробовал несколько раз подряд ввести заведомо неправильный пароль. Раз 5-7 вводил. После чего спокойно зашел под ранее созданным паролем. Никакой блокировки нету. Или вы отключили эту опцию?
Здравствуйте. Почему-то после первого коммента у меня на других сайтах авторизация запоминается, а на вашем сайте её всякий раз надо по новой вводить.
Немного поюзал iThemes Security и удалил. Во первых немного тяжеловат он в загрузке, если смотреть через P3. Во вторых много лишнего. В третьих заметил что логин админа ещё через его ник наверху в статьях палится, если от него статьи публиковать или через вашсайт.ru/?author=1 , если конечно id не изменён. Код, как обычно рекомендуют, искать и менять было лень, поэтому применил плагин, который начисто удалил, где только можно, все упоминания об админе. Заодно вставил код блокирующий админ-панель, более серьёзный чем вы рекомендовали. Теперь в админку не попасть никому ни под каким видом, кроме разумеется админа.
И ещё вот что хотел спросить- есть ли какой-либо плагин, который позволяет редактировать шапку записей в строке "Написал admin в 3 Октябрь 2014, 15:39"?
У вас я вижу она по другому выглядит - просто "Опубликовано 03.04.2014". Или надо php редактировать?
Добрый день.
Насчет данных при комментировании - может быть вы куки чистили? Или может быть кэширование так отрабатывает.
Да, по адресу сайт/?author=1 палится настоящий логин. Но этого можно избежать путем отображения не логина, а никнейма. Ну и id=1 нужно сменить. Также средствами .htaccess можно полностью исключить просмотр страниц сайт/?author=x, а точнее сделать редирект на 404 или на главную. Да вообще разных способов скрытия настоящего логина немало.
Насчет мета-данных в постах, тут все зависит от темы (шаблона). В некоторых есть настройка скрытия показа дополнительных данных, в некоторых нету, и тогда приходится править руками. Конкретно на этом блоге я вручную это подчищал. Ну вот как-то так.
А что за плагины вы использовали? Поделитесь названиями, если не затруднит.
Все по полочкам разложено, наконец я разобралась в этом обновлении. Спасибо огромное.
Благодарю за отзыв
Спасибо Вам огромное за такую подробную и полезную статью! Благодаря ей без проблем установила данный плагин. Теперь Ваш сайт обязательно в закладки!
Спасибо за отзыв. Забегайте в гости)
Александр, отличный мануал!
Правда, кто-то уже успел сплагиатить : http://tarassila.com/2014/05/17/plagin-ithemes-security-better-wp-security-bolee-30-sposobov-zashhity-bloga/
Пардон за ссылку - можете её потом удалить.
А у меня, собственно, вопрос.
Ранее пользовалась плагином Acunetix WP Security - теперь, можно его смело удалять? Достаточно одного iThemes Security?
Спасибо, Галина!
Acunetix да, можно удалять. Вроде все функции дублируются.
P.S.: Благодарю за ссылку. Я не против копирования своих статей, даже наоборот за их распространение, если они несут пользу. Но приписывать чужим статьям свое авторство как-то некрасиво. Написал автору блога вежливый комментарий по этому поводу. Не знаю, отреагирует или нет. Нет, так нет, на его совести.
Автор блога, укравшего пост, довольно грязно ведет свой бизнес, я уже пару раз сталкивался с ним и вряд ли ваше письмо повлияет на него, но попытку сделать нужно, согласен))
Тарас Сила - легендарная личность. О таких говорят, что они могут зимой в Арктике продать снег. Для них обмишурить, взять чужое - святое дело.
Легенда - это Лев Яшин, Джон Леннон а это простой проходимец, псевдо-инфобизнесмен, продавец воздуха. Могу ошибаться, но мое мнение про этого "инфопупса" именно такое.
Легендарные личности не обязательно может бывают положительными.
Он уже довольно долго "трудиться" на ниве продажи воздуха.
Я и не думал, что он такая известная личность.
Ну да ладно. Я копирастией не страдаю =)
Одно могу сказать, мне, например, было бы жутко стрёмно говорить "я тут инструкцию написал для вас", а при этом саму инструкцию скопипастить.
Disable XML-RPC – отключение XML-RPC. То самое, о чем мы недавно говорили. Если не пользуетесь средствами удаленной публикации, обязательно отключите XML-RPC.
Какое значение выбрать? Как отключить XML-RPC?
Для полного отключения выбирайте "Completely Disable XMLRPC"
Здравствуйте, Александр такая ситуация, копирую файл .htaccess с сервера на комп. нормально, а обратно не идет. Деактивировал плагин, все равно не копирует обратно. Пишет ошибка при передаче. Пробовал на другом сайте без плагина Better WP S, нормально и туда и сюда копируется. Вы не сталкивались с такой ситуацией?
Александр извините за беспокойства, я разобрался.
Добрый день!
Вот и славненько =)
Здравствуйте, Александр!
Очень подробный перевод и инструкция - спасибо!
У меня проблема с настройками.
Начиная с рубрики "защиты от форсатак" изменения в файлах не сохраняются.
И в моей версии в этой рубрике галочка стояла по умолчанию на строке получить API ключ для сильной защиты(примерный перевод) - у вас ничего не написано про это.
Мне нужно получить этот ключ?
Добрый день, Софья.
По поводу сохранения изменений - проверьте в Glabal setting наличие галочки напротив "Allow iThemes Security to write to wp-config.php and .htaccess". Это самое первое, что нужно сделать. Если галочка стоит, но настройки не сохраняются, то попробуйте вручную выставить права, например, 644, на файлы .htaccess и wp-config.php (только потом не забудьте обратно выставить более жесткие права, например, 444).
В крайнем случае, попробуйте переустановить плагин. Также убедитесь, что никакой другой плагин не запрещает запись в .htaccess
Насчет API- ключа - в статье про это не написано, т.к. данная опция появилась много позднее. Что касается вопроса получать ключ или нет - на ваше усмотрение. Желательно, конечно, получить ключ - дополнительная защита от всяких зарубежных, да и не только, "негодяев" =)
Все проверила, удалила. Попробовала снова, но все тоже самое.
В Вордпресс СЕО есть документы Robots.txt и .htaccess для редактирования. В нем появились записи от плагина защиты, но начиная от рубрики форс атак ничего не сохраняет дальше.
Может посоветуете другой плагин для Ворд пресс.
Спасибо за советы.
Нашел похожую на вашу проблему: https://wordpress.org/support/topic/options-mysteriously-get-unchecked
Разработчик считает, что скорее всего это конфликт каких-то плагинов и советует для начала отключить все плагины (в первую очередь плагин кэширования, если он есть) и попробовать сохранить настройки в iThemes, а затем (если настройки сохранятся) активировать поочередно все плагины, пытаясь выявить "виновника" конфликта. Если же настройки не будут сохраняться даже при всех отключенных плагинах, то скорее всего (имхо) конфликт где-то на стороне веб-сервера. К сожалению, в бесплатной версии плагина техподдержка не может разбирать каждый конкретный случай и часто дает вот такие вот общие рекомендации. Но все же стоит этот вариант попробовать.
Также могу посоветовать вам обратиться с проблемой к хостеру, возможно они чего-то подскажут (особенно если даже при отключенных плагинах настройки не сохранятся).
Ну, а если все же решили отказаться от этого плагина, то могу посоветовать следующее:
1) BulletProof Security - тоже достаточно сильный плагин, но ему не хватает некоторых опций (например, он не умеет прятать админку).
2) All In One WP Security & Firewall - по описанию очень хороший плагин, но я им пока не пользовался.
3) Centrora Security- тоже очень хороший плагин (бывший OSE Firewall Security)
4) NinjaFirewall (WP edition) - периодически в буржунете встречаю инфу о нем. Видимо классный (по крайней мере по описанию очень хорош). Я пока его не пробовал.
В общем, попробуйте разные варианты.
P.S. Обязательно отпишитесь по результатам, если конечно вас не затруднит.
Добрый вечер, Александр!
Плагины оказались ни при чем. Для кеширования у меня вообще нет. Отключала все и пробовала настраивать - ничего не получилось. Удалила, поставила снова. Переписывалась весь день с хостингом.
Попросили дать вход в админ.панель. В итоге у них все работает и все сохраняет.
А у меня как не работало, так и не работает. Предложили почисть кеш браузера. Чистила, заходила с другого браузера, даже с ноутбука мужа пробовала сохранять изменения.
Ничего не получилось. При этом служба поддержки утверждает, что пробует галочки ставить в разных местах этого плагина защиты и у них все сохраняется. Вобщем грешат на мой браузер.
В итоге удалила совсем.
Поставила BulletProof Security - и через пять минут все работало.
В чем была проблема с iThemes Security (Better WP Security) так и остается загадкой.
Хотела сказать спасибо за советы и статьи в которых не просто показано на какую кнопочку ткнуть, а расписано детально для чего это нужно делать. Мне понравилось.
А то для "чайников" пишут - жми сюда и все работает. Хочется учится по ходу дела. Не век же чайником быть.
Теперь у меня другой вопрос.
Менять ли мне логин и пароль для админ панели, раз я их хостингу рассказала? И как это сделать, если нужно?
Добрый день, Софья. Да уж, очень странная ситуация. Очевидно, что проблема именно на вашей стороне - скорее всего в браузере или в его расширениях. Проверьте, все ли ваши браузеры обновлены до актуальных версий, также посмотрите какие расширения установлены - особенно типа блокировщиков рекламы и т.п. Также возможно, хотя и маловероятно, что не дает сохранить настройки какой-нибудь антивирусный модуль в вашем антивирусе, или какая-то может быть локальная программа по типу все тех же блокировщиков рекламы.
Ну, а коли уж вы перешли на BPS, то пускай это остается загадкой =) Хотя выяснить причину хотелось бы.
Что касается смены логина/пароля в админке: в целом, можете поменять (вообще рекомендуется периодически везде пароли менять). Но если подумать глобально, то в данном конкретном случае это не особо требуется - ведь это был ваш хостер, а не посторонний человек. Следовательно он и без этого пароля имеет полнейший доступ ко всему, что хранится на его серверах =)
P.S. Спасибо за то, что отписываетесь по результатам. И большое спасибо за благодарность. Я именно так и стараюсь писать, чтобы люди понимали, что и зачем нажимают, а не так просто по кнопочкам кликали =) Рад, что вы это оценили.
Спасибо за советы. Браузер вроде обновляли. особых наворотов нет никаких. По поводу хостера - и правда, чего я беспокоюсь. он и так все даннные хранит. Спасибо еще раз.
Всегда пожалуйста, Софья.
Привет Александр. Видел, статью на сайте Тараса, если бы не читал комментарии у тебя, так и не подумал бы, что она уведенная. Все равно твоя лучше и понятнее, да и общение лучше.
Наконец я закрыл доступ в админку своего магазина, оказалось очень просто. Нужно было переименовать файл: admin на хостинге. Набрал просто несколько бессмысленных букв. Теперь тех кто будет пытаться набрать admin, просто перебрасывает на главную. Интересно подобный вариант может подойти для скрытия админки в Вордпресс?
Приветствую! Спасибо)
В WordPress тоже можно переименовывать файл wp-login.php, только помимо простого переименования нужно будет проделать еще некоторые несложные манипуляции.
Здравствуйте, Уважаемый Александр!
Помогите, пожалуйста!
Я сделала непоправимую глупость! Тупо поменяла пароль для входа в панель управления. Теперь не могу зайти сама уже три дня! Помогите, пожалуйста, советом!
Спасибо заранее!
Добрый день!
А обычное восстановление пароля на почту не работает? Тогда меняйте пароль в базе данных через phpMyAdmin. Вот хорошая статья на эту тему: https://wpmag.ru/2013/izmenit-parol-v-wordpress/. Также в ней есть и другие способы. Думаю справитесь.
Если что-то не будет получаться, пишите.
Да в том то и дело, что в форме входа в админ панель у меня нет функции восстановления пароля, я же настроила плагин iThemes Security как вы пишите в статье. Ни старый ни новый пароль не принимается и просто пишут You have been locked out due to too many login attempts - Вы заблокированы.
Опять я !
Нет, я опять затупила!
В форме входа в админ панель таки есть строчка "восстановление пароля". Ввела новый пароль. Подтвердили - пароль надёжный. При входе в админ панель я ввела новый пароль, но опять та же запись - вы заблокированы. ,Куки и кеши перед этим я в браузере почистила.
Да, плагин вас заблокировал за то, что вы несколько раз ввели неправильный логин/пароль. Теперь вам нужно удалить запись о блокировке из базы данных. Вот в этом комментарии я писал, как это сделать: http://bloginfo.biz/ithemes-security-formerly-better-wp-security.html#comment-4321 Пробуйте.
После того, как из базы удалите запись о блокировке себя, пробуйте войти под тем паролем, который вы вписывали последним (после процедуры восстановления). Если опять не получится, то проведите процедуру восстановления пароля по почте еще раз.
Александр, а не проще (для меня) сделать откат и восстановить сайт из резервного БД, а то уж много незнакомых букв :) в том комментарии, куда вы меня послали? Боюсь опять что-то напортачить! Да и IP-адреса у меня меняются, я и не найду где мой.
Мне негде, когда заблокирован вход в админ панель, посмотреть текущий ид-адрес. Ко мне на почту приходят коротенькие письма и там есть такая строчка:
Lockouts: There have been 2 users or usernames locked out for attempting to log in with incorrect credentials.
На самом деле, тут ничего сложного. Это только кажется. Делайте все внимательно, и ничего плохого не произойдет (для подстраховки рекомендую сделать резервную копию БД).
1. Зайдите на 2ip.ru или whoer.net и посмотрите свой IP-адрес.
2. Если IP-адрес у вас меняется, то ничего страшного. Меняются, как правило, последние и (иногда) предпоследние пары чисел. Например, у вас могут быть адреса: 220.220.2.3, 220.220.4.5, 220.220.6.7. То есть, видите, первые два числа (если точку считать разделителем) не меняются. У вас, скорее всего, будет также.
3. Подключитесь через phpMyAdmin к базе данных (инструкции, логин/пароль к БД вам должен был хостер выдать) и найдите таблицу wp_itsec_lockouts (wp - если префикс таблиц вы не меняли). Найдите свой IP и в этой строке нажмите на значок "Удалить". Если записей в этой таблице очень много и вам сложно сориентироваться, то можете прокрутить страницу вниз, увидите примерно вот такое:
Отметьте галочкой "Отметить все" и нажмите "Удалить". Это действие очистить всю таблицу с блокировками. Только убедитесь, что вы находитесь именно в этой таблице.
Главное, не бойтесь =) Если все будете делать спокойно, внимательно, не торопясь - все у вас получится. Потом, через какое-то время, будете еще удивляться "а чего это я так боялась раньше?" =)
В целом, этому нужно учиться. Хотя бы базовые вещи уметь делать. Вы же не планируете при первой же проблеме восстанавливать сайт из резервной копии? Это не правильно. Ну, а если что-то опять не будет получаться, то пишите.
Здравствуйте, Александр!
Ура!!!, я его сделала!!, я зашла в Панель управления моего любимого!!
Спасибо Вам большое! Спасибо Вам большущее!!! Громаднешее Вам спасибо!!
Вы лучший!!! Вы самый лучший! Вы супер!
Я, по вашему совету, успокоилась - действовала же по ВАШЕМУ, Александр, совету.
Я не торопилась - сделала два перерыва на кофе и один на ночь,
Я была внимательна и не боялась, хотя и взмокла не раз.
Я сделала всё как Вы написали!
Таблица ввела меня в заблуждение - там не было моего или, хотя бы похожего цифрами, ида. Поэтому одним махом я удалила все строчки!
Потом легко и просто, крепко зажмурившись, зашла в панель управления, введя последний обновлённый пароль. И всё...!
"а чего это я так боялась раньше?"
Спасибо Вам большое!
Низкий Вам поклон! за то, что Вы помогаете таким вебмастерам, как я, особо одарённой.
Вы очень просто и понятно всё объясняете, поняла даже Я!
С Вами получилось, действительно, всё легко и просто!
Можно я вас поцелую!!??
Вы лучший из лучших!!!
Ох, Ольга, ну и засмущали вы меня =) Очень приятно слышать. Спасибо большое за теплые слова..
Видите, в принципе ничего сложного нет. Главное, как я и говорил, не бояться. Но одновременно с этим и не торопиться, быть внимательным. И всё всегда будет получаться ;)
Здравствуйте, Александр может не по теме но хочу у вас спросить, скажите пож. Вы слышали о новой инфекций для сайтов CryptoPHP? В интернете мало инфы. по этой инфекций не совсем понятно как он работает, что-то связано с картинками, и плагинами. Хотел у вас уточнить может Вы владеете какой нибудь инфой. по этой инфекций.
Добрый вечер!
Да, ходят разговоры. Но как всегда не в рунете =)
CryptoPHP распространяется через "пиратские" сайты с шаблонами для популярных CMS, точнее этот бэкдор уже находится в шаблонах/темах. Поэтому ни в коем случае нельзя скачивать т.н. "премиум шаблоны" с подобных сайтов.
Сам же бэкдор в основном используется для "черного SEO". Если интересно, то можете почитать подробный отчет компании Fox-IT по CryptoPHP. Вот прямая ссылка на него (отчет на англ.яз.): https://foxitsecurity.files.wordpress.com/2014/11/cryptophp-whitepaper-foxsrt-v4.pdf
Вот здесь эта же компания выложила скрипты для проверки сайтов на наличие данного бэкдора. Скрипты на Питоне, так что если захотите провериться, то убедитесь, что ваш хостинг позволяет запускать python-скрипты.
Вообще, как я понял, если CryptoPHP обнаружится, то проще будет полностью переустановить движок, темы и т.д., чем "лечить".
Так что, еще раз и еще раз всем напоминаю - никогда не скачивайте темы с сайтов, где предлагаются пиратские премиум шаблоны.
P.S.: Кошка, не в обиду, если ты это читаешь =)
Спасибо Александр за инфу. Займусь изучением этого паразита.
Добрый день, подскажите пожалуйста, у меня такая проблема, что иногда выскакивет ошибка
И так далее. А так же куча страниц вылетела из поиска с ошибкой 403, хотя страницы доступны. Скажите как исправить эти ошибки? А так же почему яндес робот видит ошибку 403 для страниц?
Здравствуйте, Игорь.
Если не используете на сайте плагины типа Cyr-to-Lat, то обязательно отключите в настройках iThemes Security опцию фильтрации не английских символов (non-english characters). Данная функция часто вызывает 403 ошибку.
По поводу ошибок PHP: я в этом не очень разбираюсь. Вероятно, вам нужно увеличить лимит памяти, вот тут я писал, как это сделать средствами WP: http://bloginfo.biz/ithemes-security-new-name-for-better-wp-security.html#comment-7388. Или нужно увеличить макс. время на выполнение одного скрипта, но тут уже нужно будет обращаться к хостеру. Возможно даже вам предложат перейти на более высокий тариф. Если сайт у вас не очень высоконагруженный, а от вас требуют перейти на более высокий тарифный план, то мой вам совет - меняйте хостинг.
Если все PHP-ошибки связаны только со скриптом class-itsec-file-change.php, то попробуйте для начала вообще отключить функцию мониторинга изменения файлов в iThemes Security.
В общем, попробуйте разные варианты. А лучше сразу напишите хостеру, и послушайте, что скажет саппорт, а потом оптимизируйте нагрузку, исходя из их советов (ну и моих).
Плагин Cyr-to-Lat у меня установлен, on-english characters отключена была, попробую отключить мониторинг посмотрим что будет. Спасибо
Если не сложно, отпишитесь, пожалуйста, по результатам.
ДОбрый вечер, насчет ошибки 403 пока не знаю, но вот остальные ошибки пропали после отключения мониторинга файлов. Спасибо
Здравствуйте! Извините, что не совсем по теме.
Есть проблема: нужно заблокировать доступ с чужих сайтов. Все сайты на одном ip, меняются только домены. И все они используются как прокладки - перебрасывает на рекламный сайт. Еще эти сайты каким-то образом попадают в ЯМетрику в раздел «страницы входа».
Подскажите как быть? Пробовал закрывать доступ в файле htaccess, результата нет.
Добрый день. А вы не пробовали внести "плохой" IP-адрес в список Ban Hosts данного плагина? В принципе, эта опция просто добавляет блокированный IP в .htaccess, но странно, что вам это не помогает. Вы как прописывали блокировку? Примерно так?
Добавлять в список не пробовал.
Да, блокировку прописывал этим способом.
Попробуйте. Чем черт не шутит =) Хотя по сути, как я уже и говорил, эта функция прописывает блокировку абсолютно таким же способом.
Здравствуйте, большое спасибо за такую подробную инструкцию настройки данного плагина. Со всеми настройками разобрался, кроме одной. При активации вот этой функции "Filter Suspicious Query Strings in the URL" на страничках пропадают картинки, но не все, а только которые генерируются из записей в блок "популярное". И пропадают, если только разлогиниться, если ты залогинен под админом или подписчиком все ок. http://i65.fastpic.ru/big/2015/0102/f0/136873c1644711332fe275fa0aa944f0.jpg
Может у кого есть идеи с чем может быть это связано? В заранее спасибо.
Добрый день, Антон!
Точно сказать не могу, но возможно скрипт, генерирующий блок "популярное" добавляет в URI картинок какие-то лишние символы, которые считаются плагином подозрительными. Как с этим бороться тоже не могу сказать наверняка, но отключать опцию "Filter Suspicious Query Strings in the URL" крайне не рекомендуется (это защита от различных атак, типа XSS, SQL-инъекций и т.д.).
Также убедитесь, что у вас в названиях картинок не используются символы, кроме англ.букв, цифр, тире, точек и нижнего подчеркивания.
Спасибо большое за такой терпеливый пошаговый разбор плагина. Потратила часа полтора, но разобралась только с вашей помощью. Перестал индексировать Яндекс, все дело оказалось в этом плагине, но никак не могла сообразить - откуда что убрать и куда что поставить. Теперь добавила IP Яндекса в "белый лист" - жду результата. Ваш сайт - к себе в закладки.
Благодарю за отзыв!
Да, я тоже слышал, что плагин может блокировать роботов Яндекса. Правда сам с этим не сталкивался. Насколько я понимаю, блокировка в основном может происходить по двум причинам:
1) Активна опция "Enable HackRepair.com's blacklist feature". Хотя, повторюсь, у меня всегда эта опция включена и проблем не наблюдается. Данный список собирается и пополняется очень грамотными людьми, и вряд ли они внесут туда ботов Яндекса.
2) Ошибки на сайте, и как следствие ответы сервера с кодом 403 и 404 (а плагин банит пользователя (или бота0, если много таких ошибок). Тут решение одно - нужно исправлять ошибки.
Ну, а то, что добавили IP-адрес Яндекса в whitelist - это правильно. Только у Яндекса много разных IP-адресов, желательно их все тогда добавить.
Как раз эта функция у меня не активна была. Только после переписки с Яндексом и хостом, они оба сообщили мне один и тот же IP, я справилась с проблемой. А где (простите дилетанта) взять остальные IP Яндекса, чтобы добавить в whitelist? Также пропала индексация на Рамблере. А вообще, плагин очень тяжелый для понимания - особенно для "чайников", то бишь для меня. Интересно. что все остальные поисковики хорошо показывают сайт по запросам. а только эти два заглючили. Но, как говорится, ничего зря не делается. Зато вот к вам попала. Теперь выберу время, чтобы подробнее ознакомиться с вашими другими уроками. :)
Ну, вообще у Яндекса много различных IP-адресов в разных диапазонах. Кроме того, они имеют свойство иногда меняться. Официально они как бы не разглашаются, но в интернете можно найти. Но в целом, если и хостинг и Яндекс дали вам именно этот адрес, то только его и используйте. Не нужно мудрить.
А что вы конкретно имеете в виду под "пропала индексация"? Ведь одно дело - это высокие позиции, другое - когда в индексе вообще нет страниц сайта. Проверить, какие страницы есть в индексе можно запросом в Яндексе:
Введите такой запрос в поисковой строке Яндекса (только bloginfo.biz замените на свой домен).
Также рекомендую включить опцию уведомления о доступности сайта (не помню где именно это - или в Яндекс.Вебмастере или в Яндекс.Метрике). Это позволит, в случае чего, узнать, что по какой-то причине боты Яндекса не могут получить доступ к сайту. Уведомления на почту приходят.
Рад слышать ;)
Только вот статей и уроков у меня совсем немного :( Но все равно забегайте, спрашивайте если что. Помогу, как говорится, чем смогу
"Правда сам с этим не сталкивался"
Вот и столкнулся =) Спасибо тебе, Яндекс, за подарок к Дню защитника Отечества!! Я всегда тебя любил, Яндекс, за твою непредсказуемость =) Сайт полностью вылетел из индекса.. Думаю без iThemes Security тут не обошлось. Пошел изучать логи.
Ввела и сразу выдали мой сайт с отметкой "1 час назад". Раньше по запросам (по низкочастотным ключам) и на первой стр. был, чаще на 2-й, 3-й. И людей больше заходило. И вдруг резко посещаемость упала. Были дни - по 300 чел., потом снизилась - около 200, а до вчерашнего дня 100 еле-еле набегало. С плагином разобралась, так или из-за этого к вечеру уже к 200-м близко, или праздники закончились.
Спасибо еще раз. Удачи. Буду "отслеживать" ваши статьи :) Сейчас подпишусь на уведомления.
Да, действительно, у вас всего одна страница в индексе Яндекса.
Вот этот сервис показывает, что недавно вылетели из индекса 160 страниц: http://pr-cy.ru/a/history-tema.com
Печально. Сделал подляночку плагин. Остается теперь надеяться на скорейший возврат в индекс остальных страниц.
Спасибо за сочувствие. Я тоже надеюсь, что все вернется. С плагином через пару дней снова поразбираюсь. Хотя, честно, уж очень он тяжеловат для дилетантов.)
Кстати, я тут подумал, что может быть и нет в этом вины плагина. Подобные выкрутасы для Яндекса - не в новинку, к сожалению.
Что касается самого плагина, то да, на первый взгляд он может показаться очень сложным. Поэтому я советую спокойно и размеренно изучить его, для этого, собственно, инструкцию эту и написал =) Зато однажды во всем разобравшись, в дальнейшем будет все понятно и уже не будет казаться все таким сложным.
Я просто удивлена вашим терпением - это сколько же времени вам понадобилось, чтобы все так разобрать. :) Но все-таки после добавления рекомендуемого IP хоть главную показывает. Подожду немного, 2-3 дня, как Яндекс рекомендует, опять начну с ними переписываться. )
Да, самое верное решение - подождать, а потом, в случае неудачи, вновь начать общение с яндексоидами. Желаю вам удачи в этом деле =)
Привет,Александр.У меня с плагином получилась такая же ситуация.Из-за ошибок был заблокирован яндекс и гугл бот.В индексе остались крошки.
Я полгода назад делала изменения в урлах статей.В ноябре меняла шаблон и все это вылезло. Пришлось удалить плагин.Индексация очень медленно восстанавливается. Сейчас плагин опять поставила, но не включила ошибку 404.
Александр, я сегодня предприняла попытку прописать в файле .htaccess свои ошибки в конце файла такого вида Redirect 301 /vulkanicheskoe-ozero-indonezii/ vulkanicheskoe-ozero/
У меня ничего не получилось, сервер выдал критическую ошибку и не изменил файл.Не знаю, что делать.Понимаю, что функцию 404 просто необходимо включить.Но в вебмастере яндекса и гугла висят ошибки (не существующие урлы).Боюсь, что если в таком состоянии сайта включу эту функцию, он опять начнет выдавать ошибку 403
У меня по ходу возникла мысль.Может я не туда прописываю эти строки?После всего, что прописывает плагин, в конце перед закрытием.
# END Tweaks # END iThemes Security # BEGIN WordPress RewriteEngine On RewriteBase / RewriteRule ^index\.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] Redirect 301 /vulkanicheskoe-ozero-indonezii/ vulkanicheskoe-ozero/ # END WordPressили плагин надо выключить перед внесением этих строк.Плагин может блокировать?
Приветствую!
Сервер не дал сохранить файл .htaccess скорее всего потому, что iThemes Security выставил такие права на файл, которые запрещают запись. Смените права на 644, внесите нужные изменения => установите права обратно, какие были.
По поводу редиректа также убедитесь (уточните у хостера), что у вас включен модуль mod_alias (это как раз для директивы Redirect) или делайте через Rewrite (но там синтаксис сложнее).
В самом деле права на эти файлы отличаются. Век учись.Плагин конечно хороший, но у него так много ньюансов.Плагин у меня на сайте не дает пользоваться поиском.Не понимаю, что ему не нравится.
Да, запрет на запись в .htaccess и wp-config.php одна из базовых функций данного плагина.
Что касается поиска (да и многих других проблем, приводящих к 403 ошибкам) - скорее всего у вас активирована опция фильтрации non-english characters (фильтрация не английских символов). Если это так, отключите ее.
Это, конечно, несколько снизит уровень безопасности, но зато не будет излишних блокировок.
Кстати, вот вы мне напомнили про это (я всегда почему-то забываю =)), и я тут подумал: вполне вероятно, что именно из-за этой опции плагин блокировал ботов Яндекса, и, как следствие, страницы повылетали.
Чтобы не отключать фильтрацию не английских символов, нужно, чтобы стоял плагин по типу RustoLat, иначе ошибки 403 будут регулярными. Но это тоже не панацея. Так что здесь приходится выбирать из двух зол: или снизить чуточку безопасность, или иметь проблемы с ошибками со всеми последствиями.
P.S.: у меня стоит iThemes Security с фильтрацией non-english, и стоит RusToLat, проблем не возникало никогда.
Александр у меня более месяца плагин не стоял.Но вот после того как я его поставила бэкап пришел только один раз.Затем плагин обновился и они перестали приходить на почту.Плагин пишет, статус-ошибка и електроная почта не может быть отправлена отправителю.
Вот это лично для меня самая загадочная проблема плагина. Очевидного решения я так и не нашел. У меня такое случилось только на одном сайте и исправить ситуацию так и не получилось. В итоге я забил на это)
Пролистайте все комментарии к этой статье, мы тут поднимали уже этот вопрос, и возможные решения проблемы (но они не всегда и не всем помогают).
Если ничего не поможет, то лучше всего вообще не использовать эту функцию, а прибегнуть к отдельному плагину для бэкапов.
Александр, я пробовала ставить другой плагин бэкапов.Тоже не присылает.Пишет, что ему прописано куда отсылать. А где можно посмотреть, где прописывается эта отсылка бэкапа?
Не совсем понял вопроса. В каком именно плагине вы хотите посмотреть, или где вообще?
По поводу плагинов для резервных копий, смотрите тут, их там много. Попробуйте самые популярные, у которых больше всего положительных оценок.
Вот у этого, например, хорошие отзывы
Да попробую плагин BackUpWordPress наверное завтра. Я пока придумала из админки хостера делаю бэкап.
name nika, я тоже долго "голову морочила" с iThemes Security. Часа полтора "пошагово" по статье Александра его перестраивала. Но еще и прошлась по ссылке, которую Александр дал на видео Дмитрия; по этому видео тоже кое-что поправила и все получилось. Так что, попробуйте еще раз настроить все снова. Я - не вебмастер, а абсолютный дилетант, поэтому если что-то не получается, начинаю все снова пошагово, обращая внимания на любую мелочь. Удачи )
Совершенно верно, у Дмитрия хорошее видео по настройке этого плагина. Настоятельно рекомендую его к просмотру.
Плагин понравился своей функциональностью. Спасибо за подробное описание настроек.
Благодарю за отзыв
Уже не первый сайт навастриваю по вашему мануалу, сегодня вот с замиранием сердца, а вдруг что-то важное отключу?) Но, с предыдущими не было проблем. Замечу только что плагин обновился, добавились новые функции. Например, salt на днях. Я так понял что это смена пароля на надежный. Вы бы дописали мануал под текущие реалии.
Рад, что мануал приносит пользу
По поводу новых функций. Я как раз планирую в ближайшее время опубликовать отдельную статью обо всех новых опциях, которые не указаны в этой инструкции.
А я вообще боюсь обновлять. С таким трудом настроила )
Обновляться необходимо.
Только не забывайте делать резервные копии перед обновлениями. Так, на всякий случай.
Александр, а после обновления все настройки снова проверять надо же! И я еще не дождалась индексирования Яндексом (они ответили, что робот мои страницы уже загрузил, значит скоро проиндексирует). Подожду...
Вообще, обычно обновления всегда проходят в штатном режиме, без сбоев. Соответственно, настройки тоже не сбиваются.
Но бывает по всякому. Поэтому про бэкапы забывать нельзя.
Что то не понятное творится, достал он меня банить как админа. Редактирую страницы, бах бан. СОздаю страницы, бах бан. Как его научить отличать админа от не админа?
Первым делом отключите опцию фильтрации "Non-english characters".
В качестве дополнительной меры можете добавить свой IP-адрес в белый список. Или на постоянной основе, во вкладке "Global Settings" в поле "Lockout White List", или на временной - вкладка "Don`t Lock Yourself Temporary" => копка "Temporarily Whitelist my IP" (IP адрес будет добавлен в белый список на сутки).
Но у меня динамический IP, так что нет смысла его добавлять. Non-english characters" отключен.
Почему нет смысла?
Можно добавить по маске. Это вполне допустимо.
Или при каждом входе в админку добавлять текущий IP-адрес кнопкой "Temporarily Whitelist my IP".
Но в целом, нужно, конечно же, искать причину.
Вы можете даже снять ролик-мануал и выложить его на Youtube. Дополнительный заработок:)
Привет!
Да, сейчас видео-инструкции очень популярны. И многим пользователям действительно по видео обучаться удобней.
Но, я более консервативен в этих вопросах, и считаю, что видео далеко не всегда может заменить текст. На видео обычно как: 'нажми сюда, тыкни сюда', а я стараюсь хотя бы поверхностно объяснить, зачем, для чего и почему нужно куда-то нажимать. И убежден, что это очень важный момент. Народ сейчас и так мало читает и 'шевелит мозгами'. Любит народ, чтобы его 'взяли за ручку, провели и все показали'. Это не всегда правильное решение.
Как дополнение к основной инструкции, может быть и имел бы место быть такой подход (например, у Василия на сайте http://vellisa.ru/ хорошо реализован похожий принцип: текстовая подробная инструкция с картинками + видео), но я его реализовывать не стану.
Что касается заработка на всем этом - это для меня совершенно не первостепенно =)
Александр, вы оказались правы о том, что у меня не работал поиск из-за включенной функции non-english characters . Отключила и все стало ок.
Сейчас не включаю ошибку 404, нужно привести блог в порядок.Если я удаляла картинки и теги и они в гуглвебмастере висят как ошибки не найдено, это критично для плагина.?
Пока на блоге есть проблемы (битые ссылки, несуществующие картинки в индексе и т.д.), то вы поступили правильно, отключив 404 детект. Теперь нужно ждать полной переиндексации Гуглом (со временем он весь этот несуществующий "мусор" выкинет из индекса). Также через Вебмастер можно удалить вручную все несуществующие ссылки.
Попробуйте оба варианта, Уверен, каждый найдет своего пользователя. Будете делать новый мануал - больше картинок (пошагово). Старый мануал уже устарел. Удачи!
Да нет, не устарел. Просто нет в нем некоторых отдельных (не столь критичных) новых функций. А в целом инструкция полностью работоспособная =)
На данный момент еще зарегистрироваться требуется и получить ключ
Надежда, где именно это требуется? Если мне память не изменяет, то получать ключ нужно (при желании):
1) Для дополнительной защиты от брутфорс атак.
2) Для возможности сканирования сайта на вредоносные объекты (нужна регистрация на virustotal).
Посмотрите мою последнюю статью про новые функции iThemes Security, я там упоминал про это.
Добрый вечер, давно не было, а тут бах опять начала ошибка выскакивать
Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 23330784 bytes) in /wp-content/plugins/better-wp-security/modules/free/backup/class-itsec-backup.php on line 140
Подскажите что делать?
Добрый!
Судя по всему у вас снова перерасход памяти идет. Попробуйте поинтересоваться у хостера по этому вопросу. Вот здесь мы уже обсуждали похожую проблему: http://bloginfo.biz/ithemes-security-formerly-better-wp-security.html#comment-8561
Только тогда проблема вызывалась скриптом мониторинга файловых изменений, а в этот раз вызвана модулем резервного копирования. Если не пользуетесь этой функцией плагина (резервное копирование), то отключите ее совсем.
Ну, а в целом, нужно или оптимизировать сайт, или делать что-то с хостингом (менять тариф или сам хостинг).
А как его оптимизировать? вроде делал многое, но чувствую не достаточно. Может у вас статьи есть подходящие?
Нет, у меня таких статей нет, к сожалению. Могу порекомендовать, например, вот такую статью (в ней же ссылки на продолжение и другие похожие статьи): http://webmastermaksim.ru/wordpress/optimizaciya-wordpress-snizham-nagruzku-na-server.html
Сразу оговорюсь, не обязательно выполнять все прям по шаблону, как написано. Что-то можно не делать вообще, что-то видоизменить и т.д. Ну, в общем, посмотрите.
Если своими словами, то оптимизировать - это в первую очередь "убрать все лишнее", а также исправить и правильно настроить все остальное. Также периодически нужно проводить оптимизацию БД - можно воспользоваться этого плагином WP-Optimize (в интернете много инструкций). Кроме того, нельзя забывать про кэширование, оптимизацию изображений и т.п.
А главное - смотреть логи ошибок, и по возможности их устранять.
В общем, это целый комплекс.
Добрый вечер.Опять я прочитала ВСЕ ваши комментарии и пояснения.Долго читала)
Хочу еще раз сказать что вы большой молодец!!!!!
У меня опять проблема.Заметила что уже месяц у меня не происходит backup.
В настройках плагина все нормально.Что вы можете посоветовать?
Еще вопрос: У меня взломали комп(.Переживаю как бы не увели сайт...может вы посоветуйте что мне сделать.Как проверить если сайт взломали тоже.Может ссылка с решением проблемы у вас есть?
Здравствуйте, рад видеть вновь (жаль, что снова с проблемой).
Про Backup, вот хоть убейте, но так и не знаю и не нашел решение этой проблемы :( Так что, придется, наверное, отключить эту функцию плагина и воспользоваться другим, специальным.
А по поводу компа.. Сложно сказать.
Что вы подразумеваете под "взломали"?
Ну, а так, алгоритм действий в таких случаях стандартный. В общих чертах:
1) Чистим/лечим комп.
2) Меняем в важных местах пароли (лучше вообще везде)
Что касается сайта. Опять же слово "взломали" слишком обширное. Могли, например, получить доступ к хостингу (т.к. комп "взломан", могли украсть и пароли), тогда с сайтом может быть все, что угодно. Но это все предположения.
На базовом уровне проверить сайт можно многими способами:
1) Панели Веб-мастера в Гугл и Яндекс.
2) На сайте https://www.virustotal.com/
3) На сайте http://sitecheck.sucuri.net/
И т.д.
Если эти сервисы не забьют тревогу, то, в принципе, не о чем волноваться. Но это далеко не гарантия, т.к. нет глубокой проверки. Но все же, этого хватает. Обычно, если на сайте появляется какой-то вредоносный код, об этом достаточно скоро начинают быть тревогу Яндекс и Гугл. Поэтому регистрация в их панелях веб-мастера необходима любому владельцу сайта (да и вообще там много всего полезного).
Доброго времени суток!
Помогите, чем можете, пжлст:)))
Я абсолютный чайник во всем, что касается сайтов и их безопасности, поэтому сама разобраться не могу.
Установила плагин. настроила по вашей статье. Сайт перестал работать. При заходе на главную пишет, что страница не найдена (хотя меню, сайдбар с рубриками отображаются...). .
Стала последовательно отключать опции, никакого результата. Деактивировала плагин, удалила его совсем - то же самое.
При этом админка доступна и работает вроде нормально. Только ни комментариев, ни записей в ней больше нет.
Что мне делать? Если вы найдете время ответить на этот вопрос, на что я очень надеюсь. будьте добры написать подробный алгоритм действий - совет типа "нужно внести изменения в файл такой-то, а потом создать директорию такую-то" мне ничем не поможет, поскольку я, как уже было сказано выше, совершенный чайник в этих вопросах:).
Заранее спасибо.
Доброго!
В первую очередь - не паниковать и не начинать все крушить =))
Во вторую - почистить файл .htaccess. Удалить все, что находится между строк (если они есть):
# BEGIN iThemes Security
# END iThemes Security
Если в этом файле еще много всего и удаление предыдущих правил (iThemes Security) не помогло, то вообще все очистить и оставить в нем только то, что находится между строк:
# BEGIN WordPress
# END WordPress
Ну, или вообще временно удалить этот файл.
Если манипуляции с .htaccess не помогли, то пытаемся восстановить сайт из резервной копии (надеюсь они у вас есть). Можно, в принципе, не возиться с .htaccess, а сразу сделать "откат" на предыдущую версию (т.е. восстановиться из бэкапа).
Если все это не поможет, или трудно понять.. Ну, я не знаю. Могу вам на почту написать, дадите мне логины и пароли, попробую посмотреть, Потом пароли поменяете =)
Спасибо, восстановила из резервной копии!
Резервные копии - это наше всё. Никогда нельзя забывать про них.
Добрый день.Еще хотела спросить: Появился после обновления плагина подраздел : Malware scanning -как его правильно заполнить?
Виорика, вот тут я кратко писал про эту новую функцию: http://bloginfo.biz/ithemes-security-formerly-better-wp-security.html#comment-6147
И в новой статье упоминал: http://bloginfo.biz/ithemes-security-changelog.html
Александр, спасибо за статью и за то, что отвечаете в комментариях. Именно они мне и помогли. Была атака на сайт, после чего плагин сам (!) включил защиту в твиках системы и установил защиту от записи на htaccess. У меня эти опции были отключены. Пару дней билась, пытаясь понять, почему я не могу внести изменения в htaccess и как снять защиту, навязанную мне плагином. Отключение плагина, само собой, не влияло на ситуацию. И, о чудо! Из ваших ответов я узнала, что, всего-то и надо поменять права доступа к файлу и смогла таки внести изменения в htaccess)))) Спасибо!
Всегда пожалуйста, Надежда.
Добрый вечер. После установки плагина, редактирование информации пользователя стало невозможным. Приходится каждый раз отключать плагин, потом редактировать свой профиль и обратно включать плагин.
Подскажите, есть ли настройка, которая отвечает за редактирование информации о пользователе?
Добрый.
Не сталкивался с этим. А вы под каким пользователем заходите? Под Администратором? Еще попробуйте отключить функцию "Disable File Editor", если она активирована. Других мыслей на этот счет нет.
Захожу под администратором
Эта функция отключена.
Причем видно, что это с целью безопасности сделано. Потому что информацию о себе я могу редактировать, а других пользователей - уже нет.
Увы, не могу знать даже. Вспоминается только одна ситуация, когда у пользователя не корректно работала админка при активированном плагине, и проблема крылась на стороне клиента. То есть либо блокировались скрипты в браузере, либо браузер был устаревшим. Но не факт, что и у вас подобная ситуация.
Спасибо,Александр! Очень своевременный труд.. Просто хочу поделиться печальным опытом. Пытаюсь самостоятельно русифицировать этот Айтемс - ни фига.....Использую
плагин переводчик - CodeStyling Localization.Перевёл всё - около 1000 терминов. А они не сгенерировались в МО-файл. А может и генерация и произошла - но изменений -никаких.Как был везде английский язык-так он и остался.Тогда я всё удалил( в смысле плагин Айтемс), загрузился заново и стал переводить с нуля. Перевёл 5-10 слов , сгенероровал МО-файл и посмотрел на результат.Итог - перевелось только слово "безопасность" и "приборная доска". От затеи самостоятельной русификации плагина безопасности отказался ,но вот случайно наткнулся на Вашу весьма подробную работу..Мне просто интересно -почему это не получилось у меня, ведь другие плагины я переводил этим вот CodeStyling Localization без особых усилий и проблем. С уважением, Николай
Доброго дня, Николай.
Я, честно сказать, почти никогда не пользуюсь CodeStyling Localization, мне как-то привычней через Poedit. Поэтому не знаю в чем может быть загвоздка.
Мы вот тут с Артемом говорили недавно на счет перевода, да у меня все никак времени на это не найдется =( Может быть когда-нибудь дойдут руки, наконец.
PS: а вот, смотрите, в последнем обновлении плагина было изменено (улучшено):
Возможно с этим и связано то, что у вас не получилось перевести.