Как защитить WordPress от Brute Force атак


Оглавление (нажмите, чтобы открыть):

Защита страниц логина от Brute Force атак

Каждый сайт в той или иной степени, периодически или постоянно, подвергается различным атакам хакеров. Одной из наиболее распространенных атак является подбор паролей для входа на веб-ресурс — Brute Force (брутфорс) атаки. Атаки такого рода на страницы логинов сайтов были, есть и по видимому будут всегда. Бороться с ними можно и нужно, даже не взирая на то, что 100% защиты никто не сможет предоставить.

В данной заметке мы рассмотрим несколько рекомендаций с форума BulletProof Security Pro по защите блогов на WordPress от брутфорс-атак на страницы логина и регистраций. И хотя здесь будут рассмотрены примеры касательно WordPress, но те же методы с успехом могут применяться на любых других типах сайтов, для чего понадобится всего лишь внести соответствующие поправки в код.

Внимание!
Перед началом экспериментов убедитесь, что у Вас есть доступ (с возможностью редактировать) к корневому файлу сайта .htaccess и к файлам текущей темы блога WordPress как минимум по FTP или SSH, или из админ-панели хостинга.

Ограничение для логина или регистраций по IP-адресам

В предлагаемом примере защита страниц для логина/регистрации блога от Brute Force атак осуществляется с помощью .htaccess на основе IP-адресов.

Имейте ввиду, что даже легальные пользователи сайта, у которых IP адрес не будет соответствовать IP адресу (или диапазону адресов подсети), прописанному в коде, не смогут залогиниться на сайте.
Однако в код можно добавить (если это действительно нужно) дополнительные IP-адреса, как полные, так и по группам из 2-х или 3-х октетов.

В соответствии с кодом файла .htaccess данного примера доступ к странице логина сайта будет доступен только для:
— домена «yourdomain.ru»;
— сервера, на котором находится сайт с IP 69.200.95.111;
— всех IP адресов подсети 65.100.50.xxx

Внимание!
Если после использования защиты от Brute Force атак предложенным методом на основе IP-адресов Вы не смогли залогиниться на свой сайт или блог, то вероятнее всего IP вашего сайта изменяется динамически, причем в широком диапазоне. Следовательно такой тип защиты Вам может не подойти, но можно воспользоваться другим методом, на основе протокола.

Запрет логина или регистраций для посторонних на основе протокола

Данный метод позволит заблокировать более 90% попыток автоматизированных Brute Force атак, так как именно протокол версии HTTP/1.0 является типичным для автоматизированных брутфорс-атак.

После добавления этого кода в файл .htaccess доступ к странице логина блога (wp-login.php) будет заблокирован для всех запросов, использующих протокол HTTP/1.0.

Если Вы не можете войти на сайт после ограничение по IP-адресам

1) Зайдите на свой сайт по FTP или SSH и скачайте себе на локальный компьютер файл .htaccess из корневой директории сайта.
2) Отредактируйте .htaccess с помощью редактора Notepad или Notepad++ (но только не используйте для редактирования файла .htaccess редакторы MS Word или WordPad, так как они могут повредить структуру .htaccess).
3) Замените код Ограничение для логина или регистраций по IP-адресам на код Запрет логина или регистраций для посторонних на основе протокола;
4) Загрузите измененный файл .htaccess снова в корневую директорию своего сайта.

Если все же Вы не смогли залогиниться на свой сайт и у Вас нет доступа к его файлам по FTP или SSH, то тогда уж придется обращаться за помощью к службе поддержки хостинга.

Комбинирование блокировки доступа по IP и протоколу

Если страница логина была запрошена по протоколу HTTP 1.0 (который часто используют брутфорс-боты) или IP-адрес не совпадает с вашим IP (конкретным IP или по маске подсети), то доступ к странице логина будет запрещен.

Вместо xxx\.xxx\.xxx нужно будет прописать соответственно необходимые Вам октеты IP-адресов.

Разрешение доступа к странице логина только для себя

Этот метод основан на проверке дополнительного параметра (или нескольких параметров) в запросе. Например таком:

Защита WordPress от брутфорс атаки через XML-RPC

Безопасность XML-RPC

В CMS WordPress есть возможность удаленной публикации, редактирования и удаления постов и комментариев. Функциональность реализована через протокол XML-RPC .

До версии 3.5 в настройках WordPress была возможность отключить XML-RPC .

Теперь такой возможности нет, протокол подключается по умолчанию с момента установки/обновления CMS.

Использование XML-RPC небезопасно. Проблема в том, что злоумышленники могут использовать протокол для взлома вашего сайта через подбор пароля (брутфорс-атака). Вы не увидите информацию об ошибке, но заметите что скорость работы сайта сильно снизится.

Как выявить атаку?

Для выявления атаки у вас должна быть установлена панель управления ISPmanager со стандартными настройками.
Подключитесь к серверу по SSH и выполните команду:

В ответе на команду отобразятся столбцы: количество_запросов, адрес_запроса и url_запроса.

Если среди этих запросов вы видите много обращений к xmlrpc.php , скорее всего ваш сервер атакуют xmlrpc-bruteforce .

Как защититься?

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

Первый способ: редактируем wp-config.php

Подключитесь к серверу по FTP . Откройте каталог вашего сайта.Обычно это /var/www/www-root/data/www/ваш домен
В нем расположен файл wp-config.php . Откройте его для редактирования.

После нее допишите:

Второй способ: редактируем .htaccess

Как и в первом способе подключитесь к каталогу вашего сайта. Найдите файл .htaccess и откройте его для редактирования.

Добавьте в файл:

Если на вашем сервере Apache 2.4 нужно добавить другие строки:

Третий способ: сторонний плагин

Вы можете установить модуль Disable XML-RPC Pingback .
Дополнение можно загрузить с официального сайта WordPress или админ-панели вашего сайта.

Защита WordPress от брутфорса

Брутвфорс, он же brute force — это атаки на сайт жертвы с последующим поиском и подбором пароля. Пароль пытаются сгенерировать из всех возможных значений. Давайте поговорим с Вами о способах защиты от брутфорс. Наиболее частые атаки на Вордпресс осуществляются этим методом.

Системы на WordPress постоянно подвергаются брутфорс-атакам. Обычно все многократные обращения к HTTPS/HTTP страницам настолько очевидны, что IP-адрес практически мгновенно блокируется. Для доступа к сайту тихим способом начали обходить защиту через XML-RPC. Начиная с версии 3.5+ и старше, опция активна.

Проблема заключает в том, что большинство средств защиты WordPress отвечают только на попытки воздействия через wp-login.php. А вот про вход через XML-RPC забывают. Отслеживать HTTP-логи бесполезно, в них ничего видно не будет. Атакующие беспрепятственно взаимодействуют с сайтом, в случае неудачной попытки они максимум получают ответ error 403.

3,0,1,0,0

1. Убираем навсегда пользователя Admin

Если Вы уже разобрались с этой проблемой, то сразу переходим ко второму пункту. Начиная с релиза WordPress 3.0+ и выше, сделать это можно простым способом. Создаем аккаунт нового пользователя, выставляем права администратора. Старого пользователя с ником «Admin» — затираем. В процессе удаления Вам будет предложено передать права на записи старого пользователя к новому.

Старые версии WordPress используют следующие запросы через MySQL:

UPDATE wp_users SET user_login = ‘Ваш новый логин’ WHERE user_login = ‘Admin’;
UPDATE wp_posts SET post_author = ‘Ваш новый логин’ WHERE post_author = ‘admin’;

6,1,0,0,0

2. Администратор сайта WordPress со сложным паролем

Пароль должен содержать минимум 12 знаков. И конечно, не забываем про использование разного регистра знаков.

3. Когда осуществляется brut force атака, сайт WordPress подвергается массированному натиску запросов к «wp-login.php». Лучше, если защита будет носить двойной характер.

В случае, когда администратор у сайта один, то можно воспользоваться только одним статичным IP-адресом. Остальные IP-адреса для доступа к «wp-admin» блокируем с помощью .htaccess.

9,0,0,1,0

order deny,allow
deny from all
allow from IP

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

order deny,allow
deny from all
allow from IP1
allow from IP2
allow from IP3

13,0,0,0,1

Соответственно, IP1,2,3 — это наши модераторы WordPress. Таким образом, мы просто отсеиваем всех юзеров (они же боты) со статичными IP-адресами (или динамичными). Для нас даже не важно, с какого именно IP адреса будут заходить. Мы разрешили вход только нескольким пользователям и все. Для остальных доступ к файлу wp-admin/wp-login.php будет закрыт. Их будет приветствовать ошибка 403.

(2 оценок, среднее: 5,00 из 5)

Админ, нас атакуют или Как защитить дедик от брута

Любому серверу для хорошей работы нужны три вещи: топовое железо, надёжное подключение и грамотный админ. Но всё это станет бессмысленным, если не обеспечить защиту от атак и взлома. Из нашей статьи вы узнаете, как защитить дедик от брута и не потерять свои данные, важные настройки и другие результаты кропотливой работы. А если слова «rdp», «дедики» и «брут» вам ни о чём не говорят, то мы восполним эти пробелы.

Дедик, dedik, dedicated — зачем нужен выделенный сервер

Если вы далеки от администрирования, то могли подумать, что Дедик и Брут — это два друга (или недруга?) с экзотическими именами. Но нет — слово «дедик» образовалось от английского dedicated, а точнее Dedicated server. Сленговое название «дедик» означает, как нетрудно догадаться, выделенный сервер. Опытные пользователи уже знают обо всех преимуществах физических серверов, но на всякий случай мы напомним.

Dedicated server — это, по сути, полноценный компьютер, расположенный в дата-центре провайдера в отдельной стойке и работающий 24 часа в сутки 7 дней в неделю. В отличие от виртуального хостинга, на нём не будут размещены сайты других клиентов, что, несомненно, даёт ощутимые преимущества:

— Все ресурсы принадлежат вам, что делает работу сервера более стабильной.

— Можно выбрать любую версию любой операционной системы и настроить её на своё усмотрение, а также установить необходимое ПО.

— Вы будете осуществлять полноценное администрирование своего сервера с root-правами.

— Всё оборудование полностью изолировано и находится в отдельной стойке, что повышает безопасность и сохранность данных.

И, конечно же, на выделенном сервере нет ограничений на количество сайтов, баз данных и почтовых ящиков. Обычно «дедики» используются для крупных ресурсов или проектов, которым необходимо обеспечить бесперебойную работу даже при большом наплыве посетителей.

Но довольно теории, перейдём к практике. Представим, что ваш сайт вырос, просмотры растут, вы перенесли его на отдельный сервер — теперь можно радоваться новым возможностям и высокой пропускной способности. Так ли всё радужно на самом деле?

Что такое брут и с чем его едят

Слово «брут» или «брутфорс» произошло от английского brute force, что в переводе означает «грубая сила». Но к дракам это не имеет никакого отношения. Метод brute force — один из способов взлома или хакерской атаки. Его суть состоит в простом переборе огромного числа различных сочетаний символов с расчётом на то, что однажды взломщик подберёт нужную комбинацию — ваш пароль.

Первые кандидаты на разоблачение — простые пароли вроде “12345678”, “admin”, “qwerty” и прочие. Следом за ними идут популярные слова, имена, названия, даты. Брутфорсеры используют специальные словари, в которых содержатся тысячи примеров наиболее частых паролей. И поверьте, “alexandr01” или “parol1324” точно не относятся к разряду надёжных.

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

Что же значит «брутить дедики», и чем опасен взлом? Ответ на первый вопрос мы уже получили — злоумышленник начнёт предпринимать многократные попытки авторизации на вашем сервере, перебирая различные пароли. Для этого он будет использовать один из известных протоколов удалённого доступа: обычно это SSH (Secure Shell) у Linux-серверов и RDP (Remote Desktop Protocol) у Windows Server. Брут отличается от DDoS-атаки тем, что хакеру важно сохранить работоспособность ресурса, поскольку чаще всего он собирается использовать его для своих нужд.

Взлом причиняет вред уже на стадии попыток — система будет хранить логи неудачных входов, размер которых может достигать нескольких гигабайт. Если своевременно не очищать их, нагрузка станет довольно существенной. Чересчур активные и продолжительные атаки приведут к падению производительности и снижению скорости работы. При этом конфигурация, тип и версия операционной системы не играют роли — брутфорсу подвержены абсолютно любые серверы.

В случае успешного взлома хакер получает полный доступ к вашей удалённой машине, и далее возможны два варианта развития событий. Первый — злоумышленник начнёт «портить» ваши файлы и данные вплоть до их удаления, устанавливать вирусы и вредоносные программы. И второй — взломщик постарается вести себя как можно незаметнее, чтобы использовать сервер в своих целях. Например, для тех же DDoS-атак или для создания ботнета.

Чтобы обхитрить хакера, вы должны думать, как хакер

Теперь настало время ответить на главный вопрос: как уберечь сервер от брута? Один из самых простых советов, которым, тем не менее, не следует пренебрегать — своевременно обновлять систему и ПО сервера. Также можно установить ряд дополнительных программ и настроек. Рассмотрим несколько наиболее действенных стратегий.

Чекер

Первый и самый простой способ — установить специальную программу-чекер, которая будет проверять существующих на сервере пользователей. Вы сможете отслеживать IP-адреса, прокси, страну и город, что сразу позволит вычислить подозрительные аккаунты. Среди примеров таких программ: Lazy SSH, SSH checker, SSH Fresh checker для Linux-серверов.

Но чекер не предотвращает сам брут, а только находит тех, кому он удался. Поэтому для защиты от попыток взлома придётся покопаться в настройках сервера. Об этом ниже.

Смена порта

Довольно тривиальный, но иногда действенный метод — поменять номер порта. Обычно все брутфорс-атаки направлены на стандартный порт 22. В файле конфигурации можно изменить его на 23 или любой другой — тогда вероятность попытки взлома снизится в несколько раз. Правда, этот способ не защитит вас от более умных хакеров, которые «брутят» все открытые порты, а также от целевых атак, направленных на конкретного пользователя или сервер.

SSH-ключи

Самый надёжный вариант — вообще отказаться от авторизации по паролю и использовать SSH-ключи. Это более безопасный способ, поскольку ключи практически не поддаются расшифровке. Их можно сравнить с ключами от вашего дома: они полностью уникальны, и открыть дверь смогут только те, кому вы их доверите. Подробнее о создании и использовании SSH-ключей можно прочитать в нашей справке.

Ограничения на авторизацию

Если вы по каким-то причинам всё равно предпочитаете использовать пароли, можно задать более строгие требования к аутентификации. Например, ограничить доступные попытки входа, указать максимальное число активных пользователей, завести чёрный список IP-адресов, задать тайм-аут, в течение которого нельзя повторно запросить авторизацию, и так далее. Но учтите, что некоторые из этих способов могут создать дополнительные проблемы для «хороших» юзеров — например, если кто-то из них случайно введёт неправильный пароль несколько раз.

Что делать, если ничего не помогает

Вы поставили надёжный пароль, проверили активных пользователей, ограничили число авторизаций, но ресурс всё равно тормозит и медленно откликается? Возможно, злоумышленники успели проникнуть на сервер заранее и «замести следы», оставив бэкдор, или же придумали новые хитроумные способы обхода ваших методов защиты. Важно понимать, что ни один из описанных выше советов не даст 100% гарантии. И хотя центры обработки данных защищены от широкополосных атак, оградиться от целевого брута крайне сложно.

Взлом сервера и доступ злоумышленников к важным данным может привести к критическим последствиям и потере огромных сумм денег: например, из-за отсутствия защиты от брутфорса в системе бронирования могла пострадать 141 авиакомпания. Также известны случаи многократных попыток взлома сайтов, работающих на WordPress, с целью нелегального майнинга или дальнейших атак. Защита сервера от подобных ситуаций — непростая задача, требующая вмешательства высококвалифицированных специалистов по безопасности. Многие провайдеры вместе с арендой сервера предлагают услуги администрирования — поэтому, чтобы обезопасить «дедик», лучше доверить его профессионалам.

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

Итак, подводим итог: не забывайте о защите своего сервера, предпочитайте SSH-ключи стандартной авторизации и всегда создавайте только надёжные пароли. Не пренебрегайте профессиональными услугами администрирования, если для вас важна безопасность и сохранность данных. Помните: даже если вы используете выделенный сервер для личных нужд, это не значит, что он автоматически становится невидимым. Хакеры не дремлют!

Напишите в комментариях, сталкивались ли вы со взломом: может быть, кто-то получал доступ к вашему аккаунту в социальных сетях или почте? Удалось ли злоумышленнику реализовать свой коварный план? Надеемся, что советы в нашей статье помогут вам избежать взлома не только серверов, но и других ресурсов.

А если вы хотите узнать о способах защиты своего личного компьютера — рекомендуем к прочтению нашу статью Как защитить свой компьютер и смартфон от взлома.

Как защитить сайт на WordPress от брутфорса (перебора паролей)

Довольно часто сайты, созданные на движке WordPress, подвергаются различным атакам. Одной из самых регулярных атак, является брутфорс. Т.е. попытка заполучить доступ к вашему сайту посредством автоматического подбора паролей. Этим занимаются боты. Беда заключается еще и в том, что такая атака провоцирует случайную DDoS, и в результате этого из-за перегрузки на процессор сайт может вовсе вырубиться.

Для решения этой проблемы обычно рекомендуется изменить имя login.php (файл для входа/регистрации на сайт). Но этот способ не самый удачный, так как при обновлении движка могут возникнуть проблемы. Ведь файлы WP обновляются. Что же делать?

На помощь приходит замечательный плагин Limit Login Attempts. Из его названия можно догадаться, что он накладывает определенный лимит на попытки входа на сайт. Например, если вы три раза ввели логин и пароль неправильно, то данный плагин заблокирует ваш ip на некоторое времени.

Количество попыток входа, а также время изоляции можно назначить в настройках плагина. Со своей задачей он справляется очень здорово. После установки, через один или два дня он наверняка поймает нескольких ботов, пытавшихся проникнуть на ваш сайт. Скачать плагин можно в оф. репозитории WP, либо через админку в «Плагины — Добавить новый», введя в поисковую строку название плагина.

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

Ломаем и защищаем WordPress своими руками

Содержание статьи

WordPress — это удобная блог-платформа для публикации статей и управления ими, на которой базируется огромное число различных сайтов. Из-за своей распространенности эта CMS уже давно является лакомым куском для злоумышленников. К сожалению, базовые настройки не обеспечивают достаточного уровня защиты, оставляя многие дефолтные дырки незакрытыми. В этой статье мы пройдем типичным путем «типового» взлома сайта на WordPress, а также покажем как устранить выявленные уязвимости.

Введение

На сегодняшний день WordPress среди систем управления контентом популярнее всего. Его доля составляет 60,4% от общего числа сайтов, использующих CMS-движки. Из них, согласно статистике, 67,3% сайтов базируется на последней версии данного программного обеспечения. Между тем за двенадцать лет существования веб-движка в нем было обнаружено 242 уязвимости различного рода (без учета уязвимостей, найденных в сторонних плагинах и темах). А статистика сторонних дополнений выглядит еще печальней. Так, компания Revisium провела анализ 2350 русифицированных шаблонов для WordPress, взятых из различных источников. В результате они выяснили, что более половины (54%) оказались зараженными веб-шеллами, бэкдорами, blackhat seo («спам») ссылками, а также содержали скрипты с критическими уязвимостями. Поэтому устраивайся поудобней, сейчас мы будем разбираться, как провести аудит сайта на WordPress и устранить найденные недостатки. Использовать будем версию 4.1 (русифицированную).

Мастер Йода рекомендует:  Как с помощью принципа единственной ответственности писать гибкий и модульный код

Индексирование сайта

Первым этапом любого теста обычно бывает сбор информации о цели. И тут очень часто помогает неправильная настройка индексирования сайта, которая позволяет неавторизованным пользователям просматривать содержимое отдельных разделов сайта и, например, получить информацию об установленных плагинах и темах, а также доступ к конфиденциальным данным или резервным копиям баз данных. Чтобы проверить, какие директории видны снаружи, проще всего воспользоваться Гуглом. Достаточно выполнить запрос Google Dorks типа site:example.com intitle:»index of» inurl:/wp-content/ . В операторе inurl: можно указать следующие директории:

Если сможешь просмотреть /wp-content/plugins/ , следующий шаг по сбору информации об установленных плагинах и их версиях значительно упрощается. Естественно, запретить индексирование можно с помощью файла robots.txt . Так как по умолчанию он не включен в установочный пакет WordPress, его необходимо создать самому и закинуть в корневую директорию сайта. Мануалов по созданию и работе с файлом robots.txt довольно много, поэтому оставлю эту тему для самоподготовки. Приведу лишь один из возможных вариантов:

Если в файлах, хранящихся в папке uploads , имеются сведения конфиденциального характера, добавляем к этому списку строчку: Disallow: /wp-content/uploads/ .
С другой стороны, в файле robots.txt не рекомендуется размещать ссылки на директории, которые были созданы специально для хранения чувствительной информации. Иначе этим самым ты облегчишь злоумышленнику задачу, так как это первое место, куда обычно все заглядывают в поисках «интересненького».

Определение версии WordPress

Еще один важный шаг — идентификация версии CMS. Иначе как подобрать подходящий сплоит? Существует три быстрых способа для определения используемой на сайте версии WordPress:

    Найти в исходном коде страницы. Она указана в метатеге generator :

  • Найти в файле readme.html (рис. 1), который входит в состав установочного пакета и находится в корне сайта. Файл может иметь и другие названия типа readme-ja.html .
  • Найти в файле ru_RU.po (рис. 2), который входит в состав установочного пакета и расположен по адресу /wp-content/languages/ :
  • Рис. 1. Версия WordPress в файле readme.html

    Хакер #196. Все о Docker

    Один из вариантов защиты в данном случае — ограничить доступ к файлам readme.html и ru_RU.po с помощью .htaccess .

    Автоматизация процесса тестирования

    Исследованием безопасности WordPress занялись не вчера, поэтому существует достаточное количество инструментов, позволяющих автоматизировать рутинные задачи.

    • определение версии и темы с помощью скрипта http-wordpress-info
    • подбор пароля по словарям
    • модуль для определения версии: auxiliary/scanner/http/wordpress_scanner ;
    • модуль для определения имени пользователя auxiliary/scanner/http/wordpress_login_enum .
    • перечисление установленных плагинов: wpscan —url www.exmple.com —enumerate p ;
    • перечисление установленных тем: wpscan —url www.exmple.com —enumerate t ;
    • перечисление установленного timthumbs: wpscan —url www.example.com —enumerate tt ;
    • определение имени пользователя: wpscan —url www.example.com —enumerate u ;
    • подбор пароля по словарю для пользователя admin: wpscan —url www.example.com —wordlist wordlist.txt —username admin ;
    • подбор пароля с использованием связки имя пользователя / пароль с числом потоков, равным 50: wpscan —url www.example.com —wordlist wordlist.txt —threads 50 .

    Определение установленных компонентов

    Теперь давай соберем информацию об установленных плагинах и темах независимо от того, активированы они или нет. Прежде всего такую информацию можно выудить из исходного кода HTML-страницы, например по JavaScript-ссылкам, из комментариев и ресурсов типа CSS, которые подгружаются на страницу. Это самый простой способ получения информации об установленных компонентах. Например, строчки ниже указывают на используемую тему twentyeleven:

    Далее, HTTP-заголовки, такие как X-Powered-By , могут указывать на наличие плагина (например, на плагин W3 Total Cache).

    Так как информация о плагинах не всегда отображается в исходном коде HTML-страницы, то обнаружить установленные компоненты можно с помощью утилиты WPScan (см. врезку). Только не забывай, что перебор путей плагинов зафиксируется в логах веб-сервера.
    Получив данные об установленных компонентах, уже можно приступать к поиску уязвимостей своими силами либо найти общедоступные эксплойты на ресурсах типа rapid7 или exploit-db.

    Определение имени пользователей

    По умолчанию в WordPress каждому пользователю присваивается уникальный идентификатор, представленный в виде числа: example.com/?author=1 . Перебирая числа, ты и определишь имена пользователей сайта. Учетная запись администратора admin, которая создается в процессе установки WordPress, идет под номером 1, поэтому в качестве защитной меры рекомендуется ее удалить.

    Брутфорс wp-login

    Рис. 3. Ошибки при аутентификации пользователя

    Зная имя пользователя, можно попробовать подобрать пароль к панели администрирования. Форма авторизации WordPress на странице wp-login.php весьма информативна (рис. 3), особенно для злоумышленника: при вводе неправильных данных появляются подсказки о неверном имени пользователя или пароле для конкретного пользователя. Разработчикам известно о данной особенности, но ее решили оставить, так как подобные сообщения удобны для пользователей, которые могли забыть свой логин и/или пароль. Проблему подбора пароля можно решить, используя стойкий пароль, состоящий из двенадцати и более символов и включающий буквы верхнего и нижнего регистра, числа и спецсимволы. Или же, например, при помощи плагина Login LockDown.

    Security-плагины для WordPress

    • Login LockDown — ограничивает количество неудачных попыток авторизации;
    • Revisium WordPress Theme Checker — ищет типичные вредоносные фрагменты в темах WordPress;
    • Sucuri Security — проводит мониторинг и обнаружение вредоносного кода;
    • iThemes Security (бывший Better WP Security) — многофункциональный плагин для защиты WordPress;
    • BackUpWordPress — делает резервное копирование файлов и БД;
    • Google Captcha (reCAPTCHA) — устанавливает капчу при регистрации, авторизации, восстановлении паролей и в форме комментариев.

    Заливаем Shell

    После того как мы сбрутили пароль, ничто не мешает залить шелл на скомпрометированный веб-ресурс. Для этих целей вполне сгодится фреймворк Weevely, который позволяет генерировать шелл в обфусцированном виде, что делает его обнаружение довольно сложным. Чтобы не вызывать подозрения, полученный код можно вставить в любой файл темы (например, в index.php ) через редактор темы консоли WordPress. После чего с помощью того же Weevely можно подключиться к машине жертвы и вызывать различные команды:

    Подключаем .htaccess

    Для запрета доступа к чувствительной информации лучше воспользоваться файлом .htaccess — это файл конфигурации, используемый в Apache Web Server. Рассмотрим возможности этого файла с точки зрения безопасности. С его помощью можно: запретить доступ к директориям и файлам, заблокировать различные SQL-инъекции и вредоносные скрипты. Для этого стандартный файл .htaccess для CMS WordPress 4.1 нужно немного расширить. Чтобы закрыть список файлов и папок, добавляем:

    RewriteCond % base64_encode[^(]*\([^)]*\) [OR] заблокирует ссылки, содержащие кодировку Base64. Избавиться от ссылок, содержащих тег

    CP3.ru Вебмастер

    Практические навыки администрирования, советы вебмастеру, повседневная работа в интернете.

    Защита CMS WordPress от атак на /wp-admin.

    Как защитить Админ-панель CMS WordPress от участившихся Brute-force-атак ботами.

    по материалам xaker.ru, sucuri.net и hostgator.com.

    В первой половине Апреля 2013 ведущие ресурсы по безопасности в интернете сообщают — число атак на сайты с CMS WordPress значительно возросло и достигло значений в 770000 тысяч зафиксированных случаев брутфорс-флуда (простой перебор логинов и паролей) за первые 10 дней месяца. Подобные атаки на админку вордпресса продолжаются уже довольно значительное время, например в декабре 2012 года было заблокировано 670 тысяч попыток доступа.
    Боты используют в качестве имени пользователя для авторизации такие значения (в порядке убывания популярности):

    Наибольшее количество атак (порядка 40 тысяч в сутки) идет с
    ip-адреса 31.184.238.38 (WhoIs Info).
    Хостинг-провайдеры, специализирующиеся на WP, сетуют на возросшую нагрузку серверов в связи с активностью бот-нета. Всего детектировано порядка 90 тысяч автоматических скриптов(ботов), участвующих в этой кампании.
    Даже на этот блог, который был установлен 15 апреля, 17 апреля уже были попытки Логина с ip-адреса 188.190.99.143 (WhoIs Info). Поэтому первым постом идет информация о самых простых и логичных в данной ситуации способах защиты админки WordPress.

    Защита Админки WP.

    Простейшие шаги для предотвращения несанкционированного доступа:

    • Не оставляйте login по умолчанию — admin, никогда не используйте банальные 123, test или qwerty для паролей или логинов, в идеале, пользуйтесь всегда генератором случайных паролей, генерируйте разные пароли для разных сайтов
    • В CMS WP узнать реальный login пользователя не составляет проблемы, поэтому, если вы не хотите прибегать к редактированию CSS-файлов или правке function.php, wp-config.php, .htaccess и .htpasswd (процедуры по сокрытию реального Логина администратора будут подробно описаны во второй части статьи), рекомендуется установить Плагин Stealth Login, это работает лучше, чем ничего, но уровень защиты достаточен только для отражения атаки школьников.

    В настройках плагина видим следующее:
    Заполнив две графы, опять же генерированным текстом, отметив нужные чекбоксы, жмем «Сохранить настройки» — Строчкой ниже появляется желанная ссыль.

  • Продолжая тему «Готовых Решений» — Безопасности блога нисколько не помешает установка таких популярных Плагинов, как:
    1. Login LockDown
      Опции:
      • Количество попыток Логина.
      • Время ограничения попыток на повторный вход.
      • Время Бана для IP, с которого была неудачная попытка входа с использованием неверного Логина.
      • Включает предыдущую опцию.
      • Включает Маскировку Ошибок входа.
      • Кнопка — Обновить настройки.
      • Кнопка — Разбанить отмеченные IP.

    Secure WordPress

    WordPress Firewall

  • База данных CMS тоже под угрозой — используйте префикс таблиц, отличный от заданного по умолчанию «wp_», имя пользователя БД и его пароль сгенерировать.
  • Для генерации паролей удобно использовать следующие расширения для популярных браузеров:
    PassGen — для Opera
    Strong Password Generator — для Google Chrome
    PwGen — для Mozilla Firefox
    Ищите данные расширения в репозиториях для соответствующих браузеров.

    Рассмотрим следующую таблицу (источник — Wikipedia Полный_перебор):

    Кол-во знаков Кол-во вариантов Стойкость Время перебора
    1 36 5 бит менее секунды
    2 1296 10 бит менее секунды
    3 46 656 15 бит менее секунды
    4 1 679 616 21 бит 17 секунд
    5 60 466 176 26 бит 10 минут
    6 2 176 782 336 31 бит 6 часов
    7 78 364 164 096 36 бит 9 дней
    8 2,821 109 9×10 12 41 бит 11 месяцев
    9 1,015 599 5×10 14 46 бит 32 года
    10 3,656 158 4×10 15 52 бита 1 162 года
    11 1,316 217 0x10 17 58 бит 41 823 года
    12 4,738 381 3×10 18 62 бита 1 505 615 лет

    Данная таблица предполагает использование пароля из набора в 36 символов (латинские буквы и цифры), и вычислительные мощности в 100000 паролей в секунду (весьма скромные цифры в современных реалиях).
    Следовательно — пароли длинной до 8 символов, состоящие только из букв и цифр, паролями вообще называть нет смысла, они являются простой формальностью, при условии, что известен реальный Логин администратора. К счастью, сейчас на большинстве сайтов есть возможность использовать в паролях буквы нижнего/верхнего регистра и специальные символы (^%$#&@*).
    В связи с вышесказанным, убедитесь что ваши пароли на всех сайтах содержат буквы в разных регистрах, цифры, и спецсимволы, а также имеют длинну более 8 символов.

    Пропишите ваши уникальные ключи безопасности в файле wp-config.php

    wp-config.php — это файл конфигурации CMS WP, здесь хранятся настройки движка. Находится файл в корне CMS.
    Найдите в файле строки:

    Вместо *** необходимо вписать свои значения ключей безопасности. Сгенерировать подходящие можно на сайте wordpress_secret-key.
    Для новых версий/для версий ниже 2.6.0
    С помощью замены этих ключей также можно сделать недействительными cookies посетителей сайта если это необходимо. То есть всем пользователям придётся логиниться заново.
    Если сервер для вашего хостинга поддерживает SSL-шифрование, можно включить данный протокол для административной части сайта через тот же wp-config.php (настройки Сертификатов Безопасности будут рассмотрены во второй части статьи):

    Использование .htaccess и .htpasswd

    Следующим шагом в деле защиты админ-панели WordPress будет использование для этой цели служебных файлов вашего web-server. Если ваш unix-хостинг работает с Apache, а это в 90% случаев именно так, рекомендуем обратиться к файлам .htaccess и .htpasswd в корне директории вашего сайта.

    Редактировать их можно с помощью обычного блокнота windows (не забывайте создать резервную копию), но вы must_have notepad++ (это мощный, легкий и бесплатный редактор для кода)

    Запрещаем доступ к файлу wp-config.php по протоколу http для всех ip-адресов:

    Прописать данное правило необходимо в файле .htaccess для директории нахождения файла конфигурации (wp-config.php) — Обычно это корень сайта,
    Но! Начиная с версии WP 2.6.0 появилась замечательная возможность!
    Вы можете перенести ваш wp-config.php на один уровень выше корня и движок самостоятельно, без каких-либо действий с вашей стороны, обнаружит его там.
    Для переноса файла вам, конечно, нужен непосредственный и полноценный доступ по FTP к структуре каталогов веб-сервера, у всех нормальных хостинг-провайдеров такая возможность есть. Если вы не можете перенести ваши файлы куда угодно в пределах выделенной вам полезной площади на сервере, смените хостинг.
    То есть, если вы перенесли конфигурационный файл — в директории с ним не забудьте отредактировать файл .htaccess с кодом, указанным выше. Если файл отсутствует — создайте его.
    Теперь злоумышленнику будет необходимо получить доступ к вашему FTP, чтобы изменить конфигурацию, или узнать пароль и логин от базы данных, которые хранятся в этом файле. Или же просто перехватить ваш трафик, предварительно вычислив ваше месторасположение, но зачем ему ради пары вирусов сидеть и настраивать скрипт для вашего сайта, ведь в интернете существует превеликое множество абсолютно незащищенных страниц. В любом случае, получив доступ к FTP, злоумышленник сможет сделать с сайтом всё что угодно.

    Переходим к работе с .htpasswd

    .htpasswd работает в паре с .htaccess. По умолчанию, никакого файла .htpasswd в корне сайта вы не найдете. Вы должны создать его. Можно создать в каталоге wp-admin (1), а можно поступить ещё более запутанным способом, разместив его, например, в папке httpdocs вашего сервера (2), если у вас есть доступ, и веб-сервером является Apache.
    .htpasswd предназначен для хранения паролей и другой служебной информации при ограничении доступа по http и https протоколам с помощью файла .htaccess.
    Как это работает:

      В директории, куда нам надо ограничить доступ, в данном случае /wp-admin, создаём файл .htaccess, следующего содержания

    Где:
    AuthName «***» — это сообщение сервера, в примере на картинке — это «adm»

    AuthUserFile /yourhosting/ваш хостинг.ru/httpdocs/example.com/.htpasswd — полный путь к файлу с паролями для случая (1), в случае (2) — путь соответственно корректируем.

  • Для unix-серверов пароль должен храниться в зашифрованном виде, поэтому проще всего будет воспользоваться сервисом для генерирования .htpasswd по адресу https://www.htaccesstools.com/htpasswd-generator/
    Там же вы найдёте другие полезные инструменты:
    Аутентификация .htaccess
    Мини-скрипт для определения пути к файлу на сервере
  • Генерируем файлы, правим путь, заливаем по FTP на сервер
  • .
  • PROFIT!
  • Дополнительные меры безопасности

    Среди других рекомендаций по защите админ-панели WordPress можно выделить удаление Пользователя с id#1, то есть учетной записи администратора Блога, создаваемой при установке CMS, Именно на неё большинство атак. Или же, при необходимости, можно не удалять запись, а понизить роль с администратора до подписчика. Делается это так:

    • cоздаем новую учетную запись с ролью администратора
    • выходим из панели и логинимся под новой записью
    • удаляем или изменяем роль предыдущей

    И не забывайте вовремя устанавливать обновления для WP и плагинов.

    О других методах защиты и обнаруженных уязвимостях в WordPress будет рассказано во второй части статьи по данной теме.

    Brute-force атаки с использованием Kali Linux

    Brute-force (атака полным перебором) – метод решения математических задач, сложность которого зависит от количества всех возможных решений. Сам же термин brute-force обычно используется в контексте хакерских атак, когда злоумышленник пытается подобрать логин/пароль к какой-либо учетной записи или сервису.

    Рассмотрим инструменты, которые можно использовать для выполнения brute-force атак на SSH и WEB-сервисы, доступные в Kali Linux (Patator, Medusa, Hydra, Metasploit), а также BurpSuite.

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

    Brute-force SSH

    Для примера возьмем тестовую машину 192.168.60.50 и попробуем подобрать пароль пользователя test по SSH. Мы будем использовать популярные пароли из стандартного словаря rockyou.txt.

    Patator
    Для подбора пароля средствами Patator используем команду:

    patator ssh_login host=192.168.60.50 user=test password=FILE0 0=/root/wordlist -x ignore:mesg=’Authentication failed’

    где:
    ssh_login — необходимый модуль
    host – наша цель
    user – логин пользователя, к которому подбирается пароль или файл с логинами для множественного подбора
    password – словарь с паролями
    -x ignore:mesg=’Authentication failed’ — команда не выводить на экран строку, имеющую данное сообщение. Параметр фильтрации подбирается индивидуально.

    Hydra
    Для подбора пароля используя Hydra выполним команду:

    hydra -V -f -t 4 -l test -P /root/wordlist ssh://192.168.60.50

    где:
    -V – показывать пару логин+пароль во время перебора
    -f – остановка как только будет найден пароль для указанного логина
    -P – путь до словаря с паролями
    ssh://192.168.60.50 – указание сервиса и IP-адрес жертвы

    Medusa
    Для подбора пароля с использованием Medusa выполним команду:

    medusa -h 192.168.60.50 -u test -P /root/wordlist -M ssh -f -v 6

    где:
    -h – IP-адрес жертвы
    -u – логин
    -P – путь к словарю
    -M – выбор модуля
    -f – остановка после нахождения валидной пары логин/пароль
    -v – настройка отображения сообщений на экране во время процесса подбора

    Metasploit
    Произведем поиск инструмента для проведения brute-force атаки по SSH:
    search ssh_login и получили ответ:

    Для просмотра необходимых параметров, воспользуемся командой show options . Для нас это:
    rhosts – IP-адрес жертвы
    rport – порт
    username – логин SSH
    userpass_file – путь до словаря
    stop_on_success – остановка, как только найдется пара логин/пароль
    threads – количество потоков

    Указание необходимых параметров производится через команду «set«.

    set rhosts 192.168.60.50
    set username test
    set userpass_file /root/wordlist
    set stop_on_success yes
    set threads 4
    set rport 22

    Указав необходимые параметры набираем команду «run» и ждем.

    Противодействие

    Ограничить количество устанавливаемых соединений с использованием межсетевого экрана. Пример настройки iptables:

    -A INPUT -i eth0 -p tcp —dport 22 -m connlimit —connlimit-above 1 —connlimit-mask 32 -j REJECT —reject-with tcp-reset .

    Такое правило установит ограничение доступа к SSH для каждого IP-адреса до 1 соединения в секунду, значительно усложнив перебор. Также эффективным решением может быть использование двухфакторной аутентификации (например, используя eToken) или аутентификации с использованием ключевой пары, а также использование ACL на основе IP-адресов.

    Brute-force WordPress

    Рассмотрим другой пример — подбор пароля окна авторизации веб-формы.

    Для примера будем подбирать пароль от учетной записи администратора wordpress.

    BurpSuite
    Для начала нам необходимо понять, как происходит процесс авторизации. Для этого мы будем использовать BurpSuite. Нам необходимо попробовать авторизоваться с любым паролем и логином, чтобы посмотреть какие запросы проходят через BurpSuite.

    Отлично, мы увидели POST запрос для авторизации с ним мы и будем работать.
    В BODY указано какой логин и пароль проверялись, а значит, мы можем попробовать самостоятельно подставить нужные нам значения.
    Передаем этот запрос в Intruder и там выбираем необходимые параметры для атаки. В пункте Payload Positions тип атаки оставляем sniper, но для проверки оставляем только параметр pwd. Таким образом, при атаке будет изменяться только этот параметр.

    Загружаем необходимый словарь и начинаем атаку.

    Из поведения веб-приложения мы видим, что неверный пароль возвращает код ответа 200. После перебора словаря, видим, что один из паролей дал ответ с кодом 302 — он и является верным.

    Данный метод перебора занимает намного больше времени, чем при использовании Patator, Hydra, Medusa и т.д. Даже с учетом того, что мы взяли небольшой словарь, BurpSuite перебирал словарь около 40 минут.

    Hydra
    Попробуем подобрать пароль с помощью Hydra.
    Как мы уже знаем, при неверной авторизации возвращается код 200, а при успешной – 302. Попробуем использовать эту информацию.
    Для запуска используем команду:

    hydra -V -f -l admin -P /root/wordlist -t 4 http-post-form://192.168.60.50 -m «/wp-login.php:log=^USER^&pwd=^PASS^&wp-submit=Log+In&redirect_to=http%3A%2F%2F192.168.60.50%2Fwp-admin%2F&testcookie=1:S=302»

    Здесь мы указываем обязательные параметры:
    -l – имя пользователя
    -P – словарь с паролями
    -t – количество потоков
    http-post-form – тип формы, у нас POST.
    /wp-login.php – это URL страницы с авторизацией
    ^USER^ — показывает куда подставлять имя пользователя
    ^PASS^ — показывает куда подставлять пароль из словаря
    S=302 – указание на какой ответ опираться Hydra. В нашем случае, ответ 302 при успешной авторизации.

    Patator
    Как мы уже знаем, при неудачной авторизации возвращается код 200, а при удачной – 302. Будем использовать тот же принцип, что и с Hydra:
    Запуск производится командой:

    patator http_fuzz url=https://192.168.60.50/wp-login.php method=POST body=’log=admin&pwd=FILE0&wp-submit=Log+In&redirect_to=http%3A%2F%2F192.168.60.50%2Fwp-admin%2F&testcookie=1′ 0=/root/wordlist -t 4 before_urls=https://192.168.60.50/wp-login.php -x ignore:code=200 accept_cookie=1

    http_fuzz – модуль для brute-force атаки http
    url – адрес страницы с авторизацией
    FILE0 — путь до словаря с паролями
    body – информация, которая передается в POST запросе при авторизации
    -t — количество потоков
    -x – В данном случае мы указали команду не выводить на экран сообщения строки, содержащие параметр с кодом 200
    accept_cookie – сохранение параметра cookie и передачи его в следующий запрос
    Как итог – нам удалось подобрать пароль.

    Nmap
    Утилита Nmap позволяет в том числе производить подбор паролей для веб-форм авторизации, если использовать скрипт http-wordpress-brute с соответствующими аргументами:
    —script-args – добавление аргументов
    user или userdb – логин или файла с логинами
    pass или passdb — указание пароля или словаря
    thread – количество потоков
    firstonly=true – выводить результат после первого же правильного пароля

    nmap 192.168.60.50 —script http-wordpress-brute —script-args ‘user= admin,passdb= /root/wordlist, http-wordpress-brute.thread=3, brute.firstonly=true’

    Противодействие

    Ограничить (усложнить) brute-force атаки на web-приложения можно средствами iptables (по аналогии с SSH) и средствами nginx. Для этого необходимо создать зону лимитов:
    .
    limit_req_zone $binary_remote_addr zone=req_limits:10m rate=30r/s;
    .

    и задействовать ее:
    location / <
    .
    limit_req zone=req_limits burst=10;
    limit_req_status 429;
    .
    >

    Такие настройки позволят ограничить количество запросов с одного IP-адреса до 40 в секунду.

    Усложнить задачу перебора можно используя следующие методы:
    — Применение межсетевого экрана и прочего ПО для ограничения количества обращений к защищаемому сервису. О том, как мы используем машинное обучение для выявления подобных атак (в том числе распределенных), можно почитать в статье.
    — Использование средств, препятствующих быстрой проверке корректности ключа (например, Captcha).

    Заключение

    В данной статье мы поверхностно рассмотрели некоторые популярные инструменты. Сократить риск подбора пароля можно, следуя следующим рекомендациям:
    — используйте устойчивые к подбору пароли;
    — не создавайте пароли, используя личную информацию, например: дату рождения или имя + дата рождения или мобильный телефон;
    — регулярно меняйте пароль;
    — на всех аккаунтах применяйте уникальные пароли.

    Подобные рекомендации (как и рекомендации по безопасной веб-разработке) мало кто соблюдает, поэтому необходимо использовать различные программные решения, позволяющие:
    — ограничить подключение по IP-адресу, или, если это невозможно, ограничить одновременное количество соединений с сервисом (средствами iptables, nginx и прочими);
    — использовать двухфакторную аутентификацию;
    — выявлять и блокировать подобные атаки средствами SIEM, WAF или другими (например, fail2ban).

    Защита wordpress от xml-rpc атаки

    Защита WordPress от брутфорс атаки через XML-RPC

    • Безопасность XML-RPC
    • Как выявить атаку?
    • Как защититься

    В CMS WordPress есть возможность удаленной публикации, редактирования и удаления постов и комментариев. Функциональность реализована через протокол XML-RPC.

    До версии 3.5 в настройках WordPress была возможность отключить XML-RPC.

    Теперь такой возможности нет, протокол подключается по умолчанию с момента установки/обновления CMS.

    Использование XML-RPC небезопасно. Проблема в том, что злоумышленники могут использовать протокол для взлома вашего сайта через подбор пароля (брутфорс-атака). Вы не увидите информацию об ошибке, но заметите что скорость работы сайта сильно снизится.

    Как выявить атаку?

    Для выявления атаки у вас должна быть установлена панель управления ISPmanager со стандартными настройками.
    Подключитесь к серверу по SSH и выполните команду:

    grep -h $(date “+%d/%b/%Y”) /var/www/httpd-logs/*.access.log | awk ‘‘ | sort | uniq -c | sort -rnk1 | head -10 | grep -i xmlprc

    В ответе на команду отобразятся столбцы: количество_запросов, адрес_запроса и url_запроса.

    2213 66.249.91.145 /bitrix/tools/conversion/ajax_counter.php 33 22.111.21.123 /bitrix/tools/conversion/ajax_counter.php 2 5.10.12.13 /bitrix/components/bitrix/sale.gift.product/ajax.php

    Если среди этих запросов вы видите много обращений к xmlrpc.php, скорее всего ваш сервер атакуют xmlrpc-bruteforce.

    Как защититься?

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

    Первый способ: редактируем wp-config.php

    Подключитесь к серверу по FTP. Откройте каталог вашего сайта.Обычно это /var/www/www-root/data/www/ваш домен
    В нем расположен файл wp-config.php. Откройте его для редактирования.

    После нее допишите:

    Второй способ: редактируем .htaccess

    Как и в первом способе подключитесь к каталогу вашего сайта. Найдите файл .htaccess и откройте его для редактирования.

    Добавьте в файл:

    Order Deny,Allow Deny from all

    Если на вашем сервере Apache 2.4 нужно добавить другие строки:

    Satisfy any Order allow,deny Deny from all

    Третий способ: сторонний плагин

    Вы можете установить модуль Disable XML-RPC Pingback.
    Дополнение можно загрузить с официального сайта WordPress или админ-панели вашего сайта.

    Защита WordPress от атак Brute Force приложений

    Похоже, что файл WordPress xmlrpc.php теперь стал объектом для нового типа атак. Раньше это были XML-RPC Pingback Vulnerability. Теперь это расширенные атаки Brute Force. В этой статье я расскажу о том, что вы должны знать об этой угрозе и что должны предпринять, чтобы защитить свой сайт от этого нового вредоносного воздействия.

    Что XML-RPC?

    Прежде чем перейти к описанию защиты файла xmlrpc.php, важно понять, что он делает. Как поясняется здесь:

    XML-RPC – это спецификация и набор реализаций, которые позволяют программному обеспечению работать на различных операционных системах, в различных средах, чтобы выполнять процедуру вызовов через Интернет. Это удаленная процедура вызовов, использующая HTTP для передачи данных и XML для кодировки. XML-RPC разрабатывался, чтобы передавать, обрабатывать и возвращать сложные структуры данных.

    XML-RPC позволяет удаленным платформам взаимодействовать между собой через Интернет. Если более конкретно, то файл WordPress xmlrpc.php позволяет внешним приложениям подключаться, передавать и обрабатывать данные.

    Нужен ли мне XML-RPC?

    Существуют различные плагины, которым может быть необходимо использование функционала XML-RPC для различных удаленных операций. По моему опыту, 99% сайтов на WordPress не используют файл xmlrpc.php ни для чего. Если вы уверены, что вам не нужен этот файл, то лучше удалить его, отключить или заблокировать. Вот несколько способов защиты сайта от XML-RPC угроз.

    Защита с помощью плагина

    Если вы предпочитаете решать задачи с помощью плагинов, зайдите в WordPress Plugin Directory и задайте на поиск “xmlrpc plugin” . Уверен, что вы найдете хотя бы один плагин, который подходит для отключения xmlrpc.php.

    Защита с помощью .htaccess

    Если вы хорошо разбираетесь в вопросах работы .htaccess, существует множество способов заблокировать доступ к файлу xmlrpc.php. Вот два самых простых из них:

    Блокировка xmlrpc.php помощью RedirectMatch

    # protect xmlrpc RedirectMatch 403 (?i)/xmlrpc.php

    Преимуществом этого способа является то, что не имеет значения, где вы установили WordPress. Файлы xmlrpc.

    php будут защищены независимо от того, где они располагаются в структуре папок (например, /wp/xmlrpc.php, /wordpress/xmlrpc.php, /whatever/xmlrpc.php, и т.д.).

    Этот способ также не зависит от регистра, так что вы защищены от любых вариаций атак типа «все прописные«.

    Блокировка xmlrpc.php помощью Order/Deny

    # protect xmlrpc Order Deny,Allow Deny from all

    Лично я предпочитаю именно этот способ защиты от атак XML-RPC. Он простой, продуманный, надежный и не требующий поддержки. Можно настроить эти .htaccess-методы защиты xmlrpc.php, чтобы, например, разрешить доступ с конкретных IP-адресов и перенаправлять блокируемые запросы на определенную страницу.

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

    Защита с помощью пользовательской функции

    Если вы не хотите использовать сторонний плагин и возиться с .htaccess, существует еще один способ защиты от расширенных атак Brute Force — отключить выполнение метода system.multicall в файле xmlrpc.php. Ниже приведена функция, которую нужно добавить в файл functions.php вашей темы:

    function shapeSpace_disable_xmlrpc_multicall($methods) < unset($methods['system.multicall']); return $methods; >add_filter(‘xmlrpc_methods’, ‘shapeSpace_disable_xmlrpc_multicall’);

    Несколько за и против этого метода:

    • За — не нужно использовать другой плагин;
    • За — не нужно использовать .htaccess;
    • Против — связан с конкретной темой;
    • Против — связан с конкретными угрозами.

    С плюсами все и так понятно, а вот насчет минусов нужно кое-что пояснить. Под «связан с конкретной темой» имеется в виду, что в принципе данная функция поможет защитить ваш сайт только тогда, когда тема, которая содержит ее, активна. Если вы переключитесь на другую тему, вы потеряете защиту. Если только вы не добавите функцию в новую тему.

    А под «связан с конкретными угрозами» имеется в виду, что эта функция отключает только system.multicall для файла xmlrpc.php. Она защищает только против расширенных атак Brute Force, нацеленных на файл xmlrpc.php. Это еще одна причина того, почему метод с использованием .htaccess является идеальным выбором для защиты сайта: он защищает от всех типов атак на XML-RPC.

    Подводя итог

    Файл WordPress xmlrpc.php является целью для большого количества различных атак. Если вы используете последнюю версию WordPress, формально у вас нет причин волноваться. Но даже в этом случае файл остается вечной мишенью для злоумышленников. Плохие парни постоянно сканируют уязвимости, связанные с Pingback, расширенными атаками, brute-force атаками и всякими другими «пакостями».

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

    Перевод статьи «Protect Against WordPress Brute Force Amplification Attack» был подготовлен дружной командой проекта Сайтостроение от А до Я.

    Как избавиться от XML-RPC-атаки на WordPress-сайты?

    Несколько дней назад я заметил, что нагрузка моих сайтов на хостинг выросла в разы. Если обычно она составляла в районе 100-120 “попугаев” (CP), то за последние несколько дней она возросла до 400-500 CP. Ничего хорошего в этом нет, ведь хостер может перевести на более дорогой тариф, а то и вовсе прикрыть доступ к сайтам, поэтому я начал разбираться.

    После письма хостеру (Beget) с объяснением ситуации, я получил подробную статистику с рекомендациями по исправлению проблемы. Итак, что мы видим:

    Львиная часть запросов идет на WordPress-сайты, а именно – на обращение к файлу xmlrpc.php:

    Топ IP-адресов выглядит подобным образом:

    Используя соответствующие инструменты (к примеру, тот же https://2ip.ru/whois/), выясняем, что первые два IP (5.196.5.116 и 37.59.120.214) – это и есть наш атакующий. Оба IP из Франции (позже к ним присоединился еще один “француз” – 92.222.35.159). Третий по популярности IP-адрес (178.154.202.251) принадлежит поисковому боту Яндекса, его блокировать не стоит.

    Возникает острое желание заблокировать доступ к сайтам с этих двух IP-адресов, это же советует и хостер:

    Однако я решил разобраться в характере проблемы подробнее, дабы подобного не возникало впоследствии (к примеру, при смене атакующим IP).

    Что это за XML-RPC-атаки?

    XML-RPC – это стандартный механизм WordPress, который применяется в частности для механизма пингбэков. А в последних версиях WordPress, начиная с 3.5, пингбэки включены по умолчанию без возможности отключения их стандартными средствами.

    Попросту говоря, механизм XML-RPC помогает сообщать другому сайту о том, что на него появилась ссылка в новом материале. Это стандартная возможность WordPress, и она не является уязвимостью.

    Плохо становится, когда злоумышленники используют ее для спама/флуда. Используя множество сайтов, при помощи запросов с них xmlrpc.php можно устроить DDoS другому сайту (на который ссылаются).

    Подробнее об этом механизме можно прочитать в этой статье: там рассказывается о случае 2014 года, когда атака со 162 тысячи WordPress-сайтов (причем ничем не зараженных) практически “положила” DDoS-ом крупный портал.

    Что делать, чтобы избавиться от запросов xmlrpc.php?

    Ну что ж, тут, как говорится, все просто. Можно, конечно, попросту отрубить механизм XML-RPC, но это может аукнуться некорректной работой сторонних модулей, использующих его. Это можно сделать как вручную через настройку файлов .htaccess или wp-config.php, так и через установку плагинов (подробнее о всех возможных способах в этой статье).

    Но я выбрал метод, который позволит сохранить функциональность XML-RPC: установку плагина Disable XML-RPC Pingback. Он удаляет лишь “опасные” методы pingback.ping и pingback.extensions.getPingbacks, оставляя функционал XML-RPC. После установки плагин нужно всего лишь активировать – дальнейшая настройка не требуется.

    Попутно я забил все IP атакующих в файл .htaccess своих сайтов, чтобы заблокировать им доступ. Просто дописал в конец файла:

    Order Allow,Deny Allow from all Deny from 5.196.5.116 37.59.120.214 92.222.35.159

    Вот и все, теперь мы надежно защитили блог от дальнейших атак с использованием xmlrpc.php. Наши сайты перестали грузить хостинг запросами, а также атаковать при помощи DDoS сторонние сайты.

    Как защитить WordPress от XML-RPC атаки в Ubuntu? | Статьи о хостинге, настройке Linux и Windows хостинга

    WordPress — наиболее популярная блоговая система управления контентом. Это значит, что на ней создано большое число сайтов, и это несомненно привлекает к ней излишнее внимание злоумышленников.

    И сегодня мы расскажем, как защититься от XML-RPC атаки на сайт. Атака сама по себе не несет угрозы взлома сайта с дальнейшим использованием уязвимости, но она может вызвать отказ в обслуживании атакуемого ресурса.

    В данном руководстве мы рассмотрим процесс защиты от такой атаки.

    Что такое XML-RPC в WordPress?

    В WordPress XML-RPC – протокол, который вызывает удалённо некоторые действия на вашем сайте. Так, плагин JetPack используется XML-RPC для своей работы. Грешит этим и мобильное приложение WordPress.

    Но с помощью XML-RPC можно «заддосить» сайт, отправляя к сайту в единицу времени большое число запросов на выполнение каких-то действий, что довольно часто вызывает отказ в обслуживании атакуемого ресурса.

    Как определить атаку XML-RPC (в частности в WordPress)?

    Если в логах веб-сервера вы обнаружите большое количество записей типа “POST /xmlrpc.php HTTP/1.0”, то, скорее всего, вы подверглись XML-RPC атаке.

    Расположение лог-файлов веб-сервера различается в зависимости от дистрибутива Linux.

    Для выявления атак XML-RPC на Apache в Ubuntu используйте можно воспользоваться следующей командой:

    grep xmlrpc /var/log/apache2/access.log

    Если у вас работает Nginx, то используйте следующую команду:

    grep xmlrpc /var/log/nginx/access.log

    Если в результате работы этих команд вы получите большой список вида:

    111.222.333.444:80 555.666.777.888 – – [24/Jan/2020:00:03:50 -0500] “POST /xmlrpc.php HTTP/1.0” 200 674 “-” “Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)”

    то вероятнее всего ваш проект был подвержен атаке XML-RPC.

    Решение проблемы

    Вариант 1: Установка плагина Jetpack.

    В плагине JetPack есть функция Protect, которая блокирует запросы multicall протокола XML-RPC. Записи XML-RPC по-прежнему будут поступать в логи сервера, но Jetpack снизит нагрузку на базу данных сайта, создаваемую вредоносной активностью, до 80-90%.

    Вариант 2: Блокировка трафика XML-RPC вручную.

    Трафик можно заблокировать в настройках сервера Apache или Nginx. Хотим заметить, что при блокировке XML-RPC может не работать мобильное приложение и некоторые модули на сайте.

    Внесите изменения в файл конфигурации Apache:

    sudo nano /etc/apache2/sites-available/000-default.conf

    Добавьте строки в блок :

    ……… order allow,deny deny from all ………

    Сохраните и закройте файл.

    Необходимо перезапустить веб-сервер, чтобы применились настройки:

    sudo service apache2 restart

    Для редактирования Nginx-файла конфигурации, введите:

    sudo vim /etc/nginx/sites-available/example.com

    **examle.com — нужно заменить на название файла конфигурации вашего сайта

    Необходимо добавить в блок server следующие строки:

    Сохраните и закройте файл, а также перезапустите Nginx:

    sudo service nginx restart

    Проверка защиты

    Если вы выбрали метод блокировки трафика XML-RPC через файлы конфигураций apache и nginx, в логи по-прежнему будут записываться подключения, но код ответа с 200 изменится на 500.

    Запись будет выглядеть так:

    111.222.333.444:80 555.666.777.888 – – [24/Jan/2020:02:04:21 -0500] “POST /xmlrpc.php HTTP/1.0” 500 674 “-” “Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)” 111.222.333.444:80 555.666.777.888 – – [24/Jan/2020:02:04:21 -0500] “POST /xmlrpc.php HTTP/1.0” 500 674 “-” “Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)” 111.222.333.444:80 555.666.777.888 – – [24/Jan/2020:02:04:22 -0500] “POST /xmlrpc.php HTTP/1.0” 500 674 “-” “Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)”

    Что такое XML-RPC и как остановить атаку на WordPress

    XML-RPC – это протокол удаленных процедур, который позволяет удаленно взаимодействовать с вашим сайтом WordPress. Другими словами, это способ управлять сайтом без необходимости входа в систему вручную через стандартную страницу «wp-login.php».

    Он широко используется плагинами, наиболее известным из собственного плагина Jetpack от Automattic. Однако в эти дни слово «XML-RPC» получило плохое имя.

    В этой статьи мы объясним, что такое XML-RPC в WordPress и как остановить атаку XML-RPC на вашем веб-сайте WordPress.

    Включен ли XML-RPC на вашем веб-сайте на WordPress?

    Быстрый способ проверить, является ли ваш сайт уязвимым, – это посетить следующий URL-адрес из браузера:

    Если он включен, вы должны получить ответ, в котором говорится, что «сервер XML-RPC принимает только запросы POST».

    Опасности и преимущества XML-RPC

    В сообществе безопасности WordPress было много вопросов о XML-RPC. В основном есть две проблемы:

    1. XML-RPC можно использовать для DDoS-атаки
    2. Его можно использовать для повторного использования комбинаций имени пользователя и пароля

    По крайней мере, это было возможно. С тех пор WordPress подключил лазейки (https://core.trac.wordpress.

    org/ticket/34336) , которые позволили людям одновременно попробовать сотни имен пользователей и паролей. Начиная с версии 4.4, она была улучшена.

    Теперь WordPress будет молча выполнять все последующие попытки входа в систему, как только один вызов XML-RPC завершился неудачно. Большой!

    Тем не менее, есть те, кто по-прежнему обеспокоен легкостью, в то время как удаленные вызовы процедур, подобные этому, могут быть сделаны. Итак, вот несколько способов защитить ваш сайт от XML-RPC – начиная с самого легкого способа, до самого тяжелого.

    Метод 1: Отключение Pingbacks

    Это процесс, который использует ваш сервер в качестве невольного участника в атаке на другой сервер. В основном, кто-то говорит вашему сайту «Эй, этот URL-адрес, связанный с вашим блогом!», А затем ваш сайт отвечает «pingback» на этот URL.

    Кроме того, нет никакой проверки, что URL на самом деле сделал ссылку на вас.

    Сделайте это с сотнями уязвимых сайтов WordPress, и у вас есть DDoS-атака на ваших руках! Самый простой способ запретить использование вашего сайта таким образом – добавить следующий код в функции functions.php вашей темы:

    function stop_pings ($vectors) <
    unset( $vectors[‘pingback.ping’] );
    return $vectors;
    >
    add_filter( ‘xmlrpc_methods’, ‘stop_pings’);

    Способ 2. Предотвращение всех запросов на аутентификацию через XML-RPC

    Этот второй метод определяет, хотите ли вы разрешать методы XML-RPC, которые аутентифицируют пользователей. Возьмем, к примеру, публикацию блога по электронной почте. Сайт получит ваше электронное письмо, проверит вас через XML-RPC, а затем опубликует его, если совпадают учетные данные.

    Многим людям неудобно, когда XML-RPC может просто принимать случайные вызовы, подобные этому. Это привело к попыткам сотен или тысяч попыток аутентификации. Несмотря на то, что WordPress с тех пор обращался к этой конкретной форме взлома, есть те, кто рекомендует просто отключить ее.

    Для этого введите этот код в functions.php:

    Важно отметить, что это не то же самое, что и первый метод. Этот код только отключает методы проверки подлинности и оставляет все остальные нетронутыми – например, pingbacks.

    Способ 3: Отключить доступ к xmlrpc.php

    Это самый экстремальный метод, который полностью отключает все функции XML-RPC. Он требует, чтобы вы редактировали файл .htaccess в корневом каталоге вашего WordPress. Добавьте следующий код вверху:

    Order allow,deny
    Deny from all

    Если вы обнаружите, что ваша версия WordPress не имеет файла .htaccess в корневой папке, просто создайте файл со следующим кодом по умолчанию.

    RewriteEngine On
    RewriteBase /
    RewriteRule ^index.php$ – [L]
    RewriteCond % !-f
    RewriteCond % !-d
    RewriteRule . /index.php [L]

    Теперь, когда действуют выше правила отказа, попытка доступа к xmlrpc.php будет выполняться со следующей страницей:

    И это все, что нужно. Вы успешно отключили XML-RPC на своем сайте WordPress.

    Что такое xmlrpc.php в WordPress и зачем его отключать

    В WordPress всегда был встроенный инструмент для удалённого обращения к вашему сайту. Действительно, иногда нужно добраться до своего сайта, а компьютер далеко от вас. Длительное время решением был файл под названием xmlrpc.php. Однако последние годы этот файл стал большей проблемой, чем решением.

    Ниже мы подробнее разберём xmlrpc.php и почему он был создан. Мы также рассмотрим общие проблемы безопасности, которые он может вызвать и как их исправить для вашего сайта на WordPress.

    Что такое Xmlrpc.php?

    XML-RPC – это функциональное средство WordPress, которое позволяет передавать данные, с HTTP выступающим в качестве транспорта и XML – для кодирования. Поскольку WordPress не является закрытой системой и часто общается с другими системами, для этой задачи были найдены решения.

    Например, скажем вы хотите сделать публикацию на своём сайте с вашего мобильного телефона. Вам нужно использовать удалённый доступ предоставляемый xmlrpc.php.

    Главным функционалом xmlrpc.php являются возможность подключаться к сайту со смартфона, реализация трекбеков и линкбеков с других сайтов и некоторые функции, связанные с плагином Jetpack.

    Зачем был создан Xmlrpc.php и как он использовался?

    Реализация XML-RPC уходит далеко в ранние дни WordPress и даже до того, как WordPress стал WordPress-ом.

    Возвращаясь в те времена, когда интернет только недавно появился, соединения были очень медленными и процесс записи и публикации в вебе был намного сложнее и времязатратнее. Вместо внесения изменений сразу через браузер, большинство делали их в офлайне и потом копировали и вставляли свой контент уже онлайн. И этот процесс был далёк от идеала.

    Решением (на тот момент) было создание клиента для офлайн блоггинга, где вы могли составлять свой контент, затем подключаться к своему блогу и публиковать его. Это подключение осуществлялось через XML-RPC. С основным функционалом XML-RPC ранние приложения используя подобные подключения предоставляли людям возможность заходить на их сайты WordPress с других устройств.

    XML-RPC сегодня

    В 2008 году с версией 2.6 WordPress, появилась опция включения и выключения XML-RPC. Однако с релизом WordPress приложения для iPhone, поддержка XML-RPC была включена по умолчанию и не было возможности для отключения. Так осталось и поныне.

    Конечно функциональность, предоставляемая этим файлом значительно уменьшилась со временем, и размер файла уменьшился с 83kb до 3kb, он уже не играет такой роли, как прежде.

    Свойства XML-RPC

    С новым интерфейсом программирования приложений (API) WordPress мы можем ожидать, что XML-RPC будет уже отключён полностью. Сегодня этот новый API всё ещё на этапе испытаний и может быть включён только через специальный плагин.

    Хотя вы можете ожидать, что API будет включён непосредственно в ядро WordPress в будущем, что полностью исключит необходимость использования xmlrpc.php.

    Новый API не идеален, но он обеспечивает хорошую надёжную защиту, в отличие от xmlrpc.php.

    Зачем отключать Xmlrpc.php

    Самой большой проблемой, связанной с XML-RPC, является безопасность. Проблема не напрямую связана с XML-RPC, но его можно использовать для включения атаки на ваш сайт.

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

    Есть два основных слабых места XML-RPC, которые использовали в прошлом.

    Первое – использует атаку путём прямого подбора пароля (brute force attacks) для получения доступа к вашему сайту. Атакующий попытается получить доступ к вашему сайту, используя xmlrpc.

    php подбирая различные комбинации имён пользователей и паролей. Они могут эффективно использовать одну команду для тестирования сотен различных паролей.

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

    Второе – перевод сайта в офлайн путём DDoS атаки. Хакеры будут использовать обратное уведомление в WordPress для отправки его тысячам сайтов одновременно. Этот функционал xmlrpc.php даёт хакерам почти бесконечное количество IP-адресов для распространения атаки DDoS.

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

    Если вы получите сообщение об успешном завершении, вы можете остановить xmlrpc.php одним из двух подходов ниже.

    Метод 1: отключение Xmlrpc.php при помощи плагина

    Отключить XML-RPC на вашем сайте WordPress невероятно просто.

    Перейдите в раздел Плагины › Добавить новый в вашей админ консоли WordPress. Найдите плагин Disable XML-RPC и установите его, он выглядит как на картинке ниже:

    Активируйте плагин и всё готово. Этот плагин автоматически вставит необходимый код для отключения XML-RPC.

    Однако помните, что установленные плагины могут использовать части XML-RPC, и тогда его отключение может вызвать конфликт плагинов или отдельных их частей и вывод их из рабочего режима.

    Если вы хотите только отключить отдельные элементы XML-RPC, но позволить другим плагинам и функциям работать, тогда обратитесь к таким плагинам:

    • Stop XML-RPC Attack. Этот плагин остановить все XML-RPC атаки, но он позволить продолжить работу таких плагинов как Jetpack и другие автоматические инструменты и плагины, предоставляя им доступ к файлам xmlrpc.php.
    • Control XML-RPC Publishing. Это позволяет вам сохранить контроль и использовать удалённо публикации.

    Метод 2: отключение Xmlrpc.php вручную

    Если вы не хотите использовать плагин и предпочитаете делать это вручную, следуйте этому подходу. Он остановит все входящие запросы xmlrpc.php до того, как он будет передан в WordPress.

    Откройте файл .htaccess. Возможно, вам придется включить ‘показать скрытые файлы’ в файловом менеджере или FTP-клиенте, чтобы найти этот файл.

    Вставьте этот код в файл .htaccess:

    # Block WordPress xmlrpc.php requests

    order deny,allow
    deny from all
    allow from 123.123.123.123

    Заключительные мысли

    В целом, XML-RPC был добротным решением некоторых проблем, которые возникали из-за удаленной публикации на вашем сайте WordPress. Однако вместе с тем появились некоторые дыры в безопасности, которые оказались довольно опасными для некоторых владельцев сайтов на WordPress.

    Чтобы ваш сайт оставался в безопасности, рекомендуется полностью отключить xmlrpc.php, если вам не нужны некоторые функции, необходимые для удаленной публикации и плагина Jetpack. Затем вы можете использовать обходные плагины, которые позволяют использовать эти функции, при этом исправляя дыры в безопасности.

    Со временем мы можем ожидать, что функции XML-RPC станут интегрированными в новый WordPress API, который будет поддерживать удаленный доступ, не жертвуя безопасностью.

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

    Брутфорс-атаки на WordPress через XML-RPC и способ борьбы с ними

    Разработчики WordPress в последних версиях упорно оставляют по-умолчанию активным протокол XML-RPC, причем, начиная с версии 3.5, такое поведение невозможно отключить.

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

    Конечно, это удобно, однако у XML-RPC есть и обратная — любые боты могут через файл xmlrpc.php проводить брутфорс-атаки, что и было незамедлительно применено ими.

    В последнее время график обращений к файлу xmlrpc.php на разных сайтах, использующих WordPress, выглядит так:

    Видно лавинообразное увеличение обращений к этому файлу, которое на большинстве сайтов ничем не компенсируется. Обычно от брутфорс-атак защищают файл wp-login.

    php, например, с помощью популярного плагина Limit Login Attempts, пресекающего бесконечный перебор логинов и паролей. А вот про файл xmlrpc.

    php мало кто вспоминает, что в сочетании активным по-умолчанию протоколом XML-RPC дает взломщикам легкий способ получения доступа к сайту с помощью брутфорс-атаки.

    Я давно уже запретил в своих блогах использование XML-RPC, причем запретил полностью, вплоть до запрета обращения к файлу xmlrpc.php, о чем еще ни разу не пожалел.

    Какие существуют способы защиты от брутфорс-атак на файл файл xmlrpc.php? Можно, а в большинстве случаев и нужно отключить протокол XML-RPC. Это можно сделать с помощью плагинов или вручную, внедрив коды в конфигурационные файлы.

    Плагины

    Полностью отключить использование этого протокола могут несколько плагинов:

    Если вы не хотите использовать плагины, то запретить протокол XML-RPC можно вручную.

    В файле .htaccess запретить прямой доступ к файлу xmlrpc.php:

    Satisfy any Order allow,deny Deny from all

    Отключить протокол может настройка файла wp-config.php. После строчки

    require_once(ABSPATH . ‘wp-settings.php’);
    add_filter(‘xmlrpc_enabled’, ‘__return_false’);

    Отключить систему уведомлений, передаваемый через XML-RPC можно, если добавить в файл functions.php используемой вами темы следующий код:

    function remove_x_pingback($headers) < unset($headers['X-Pingback']); return $headers;>add_filter(‘wp_headers’, ‘remove_x_pingback’);

    Надеюсь, что приведенные способы защиты от брутфорс-атак через XML-RPC сделают ваш сайт более защищенным.

    Лучшая защита WordPress – плагин All In One WP Security (настройка)

    Меня взломали. Знаете как страницу во ВКонтакте. Но они не клянчили денег, а насоздавали множество «левых» страниц с ссылками на разные сайты. Тогда я задумался над защитой своего блога. И я нашел идеальное решение.

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

    Потом я установил множество плагинов для защиты ВордПресса от взлома. Но блог стал жутко тормозить. Страницы грузились по пять десять секунд. Это очень долго.

    Я начал искать плагины которые не так сильно нагружают систему. Читал отзывы по этим плагинами и все чаще стал натыкаться на All In One WP Security. По описанию он мне очень понравился и я решил поставить его себе на блог. И он защищает меня до сих пор, так как ничего лучше я не встречал.

    Что умеет All In One WP Security (защита wordpress всё в одном):

    • Делает резервные копии базы данных, файла конфигурации wp-config. и файла .htaccess
    • Смена адреса страницы авторизации
    • Скрывает информацию о версии WordPress
    • Защита админки — блокировка при неправильной авторизации
    • Защита от роботов
    • И ещё много чего полезного

    Я смело могу сказать, что плагин безопасности All In One WP Security — это лучшая защита wordpress сайта.

    Настройка All In One WP Security

    Зайдя в отдел Настройки, первым делом нужно сделать резервные копии:

    • база данных;
    • файл wp-config;
    • файл htaccess

    Делается это на первой странице настройки плагина All In One WP Security.

    сделайте бэкап (резервную копию) перед началом работы

    Пройдусь только по самым важным пунктам.

    пункты настройки плагина all in one wp security

    Панель управления

    Тут нас встречает счетчик «Измеритель безопасности». Он показывает уровень защиты сайта. Ваш сайт должен быть как минимум в зеленой зоне. Не надо гнаться за максимальной планкой — лишние настройки могут нарушить функционал сайта. Добейтесь золотой середины.

    Счетчик защиты сайта на wordpress

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

    цифра прибавляется к общему счету безопасности

    Настройки

    Вкладка WP Version Info

    Чекаем галочку Удаление метаданных WP Generator.

    Удаление метаданных WP Generator

    Делается это для того, чтобы в коде не отображалась установленная у вас версия движка WordPress. Злоумышленники знают в какой версии есть уязвимости, и зная установленную у вас версию ВордПресса смогут быстрее взломать ваш сайт.

    Администраторы

    Пользовательское имя WP

    Если у вас логин для входа в админку admin, то обязательно меняем его. Admin это самый популярный логин. Многие ЦМСки предлагают его по умолчанию, а людям просто лень его менять. Злоумышленники используют различные программы для взлома сайтов. Эти программы подбирают логины и пароли пока не найдут подходящую комбинацию.

    Поэтому не используйте логин admin.

    Отображаемое имя

    Если ваш ник совпадает с логином, то обязательно меняем логин или ник.

    Пароль

    Если ввести тут свой пароль, то плагин покажет за какое время можно взломать ваш сайт.
    Рекомендации по усилению надёжности пароля:

    • Пароль должен состоять из букв и цифр
    • Используйте строчные и прописанные буквы
    • Не используйте короткие пароли (минимум 6 символов)
    • Желательно наличие в пароле спецсимволов (% # _ * @ $ и подробных)

    Авторизация

    вкладка Блокировка авторизаций

    Обязательно включаем. Если в течении 5 минут кто-то неправильно введёт пароль 3 раза, то IP заблокируется на 60 минут. Можно поставить и больше, но лучше этого не делать.

    Может случится так, что вы сами неправильно введёте пароль и будете потом ждать месяцы или даже годы �� Отмечаем галочку «Сразу заблокировать неверные пользовательские имена».

    Допустим ваш логин hozyainsayta, и если кто-то введёт другой логин (например login), то его IP адрес автоматически заблокируется.

    опции блокировки авторизации

    Автоматическое разлогинивание пользователей

    Ставим галочку. Если вы зайдёте в админку сайта с другого компьютера и забудете выйти из админки, то через указанный промежуток времени система сама вас разлогинит.
    Я ставлю 1440 минут (это 24 часа).

    Опции автоматического разлогинивания пользователей

    Регистрация пользователей

    Подтверждение вручную

    Чекаем «Активировать ручное одобрение новых регистраций»

    Ручное одобрение новых регистраций

    CAPTCHA при регистрации

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

    Registration Honeypot (бочка мёда)

    Отмечаем. И не оставляем роботам не единого шанса. Эта настройка создает дополнительное невидимое поле (типа Введите сюда текст). Это поле видят только роботы. Так как они автоматически заполняют все поля, то и в это поле что-то напишут. Система автоматически блокирует те попытки регистрации у которых будет заполнено это поле.

    Защита базы данных

    Префикс таблиц БД

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

    обязательно сделайте резервную копию БД

    Если вы только что создали свой сайт, то можете смело менять префикс.

    Префикс таблиц Базы данных

    Резервное копирование базы данных

    Включаем автоматическое создание бэкапов. Выбираем частоту создание резервных копий. И количество файлов с этими резервными копиями, которые будут храниться. Потом они начнут перезаписывается.

    Если вы хотите, чтобы эти файлы дополнительно посылались на вашу электронную почту, то отмечаем соответствующую галочку. У меня для этих целей в почтовом ящике заведена отдельная папка, туда пересылаются все бекапы (моих и клиентских сайтов).

    Настройки резервного копирования Базы данных

    Защита файловой системы

    Доступ к файлам

    Тут меняем права доступа к файлам, чтобы все было зелёным.

    Доступ к файлам

    Редактирование файлов php

    Ставим в том случае, если вы не редактируете файлы через админку. Вообще вносить какие либо изменения в файлы нужно через программы ftp-менеджеры (типо файлзилла). Так в случае какого либо «косяка» всегда можно отменить предыдущее действие.

    Доступ к файлам wp

    Запрещаем доступ. Этим действием мы сможем скрыть важную для хакеров информацию.

    Черный список

    Если у вас уже есть IP адреса которым вы хотите запретить доступ к сайту, то включайте эту опцию.

    Блокировка пользователей по IP

    Файрволл

    Базовые правила файрволла

    Файрволл и брандмауэр это программный комплекс представляющий собой фильтр несанкционированного трафика.

    Эти правила вносятся в файл .htaccess, поэтому сначала делаем его резервную копию.

    Теперь можно проставить нужные галочки:

    Активировать основные функции брандмауэра

    Защита от уязвимости XMLRPC и Pingback WordPress

    Блокировать доступ к debug.log

    Дополнительные правила файрволла

    На этой вкладке отмечаем следующие галочки:

    • Отключить возможность просмотра директорий
    • Отключить HTTP-трассировку
    • Запретить комментарии через прокси
    • Запретить вредоносные строки в запросах (Может нарушить функциональность других плагинов)
    • Активировать дополнительную фильтрацию символов (Тоже действуем с осторожностью, надо смотреть как влияет на работоспособность сайта)
        У каждого пункта есть кнопка «+ Подробнее» там вы можете почитать подробно про каждую опцию.

    6G Blacklist Firewall Rules

    Отмечаем оба пункта. Это проверенный список правил который дает плагин для безопасности wordpress сайта.

    Настройки файрволла (брандмауэра)

    Интернет-боты

    Могут появиться проблемы с индексацией сайта. Я данную опцию не включаю.

    Предотвратить хотлинки

    Ставим галочку. Что-бы изображения с вашего сайта не показывались на других сайтах по прямой ссылке. Эта функция снижает нагрузку с сервера.

    Детектирование 404

    Ошибка 404 (такой страницы нет) появляется при ошибочном вводе адреса страницы. Хакеры перебором пытаются найти страницы с уязвимостями и поэтому вводят много несуществующих урлов в короткий промежуток времени.
    Такие попытки взлома будут заноситься в таблицу на этой странице и чекнув галочку — вы сможете блокировать их IP адреса на указанное время.

    Настройки отслеживания ошибок 404

    Защита от брутфорс-атак

    Переименовать страницу логина

    По умолчанию у всех сайтов на Вордпрессе одинаковый адрес страницы авторизации. И поэтому злоумышленники точно знают где начать взламывать сайт.
    Эта опция позволяет изменить адрес этой страницы. Это очень хорошая защита wordpress сайта. Обязательно меняем адрес. Я эту галочку не отметил, потому-что мой хостинг автоматически изменил мне эту страницу во время установки системы.

    Переименовать страницу логина

    Защита от брутфорс-атак с помощью куки

    Я не стал включать эту настройку, так как есть вероятность блокировки самого себя при входе с разных устройств.

    CAPTCHA на логин

    Если на вашем сайте много пользователей или у вас интернет-магазин, то можете включать Капчу при авторизации во всех пунктах.

    Защита капчей при авторизации

    Белый список для логина

    Заходите в админку только с домашнего компа и вы единственный пользователь своего сайта? Тогда впишите свой АйПи адрес и всем остальным доступ к странице авторизации будет закрыт.

    Только указанные в списке IP имеют доступ к сайту

    Бочка с медом (Honeypot)

    Таже знакомая нам Бочка с мёдом — скрытое поле для роботов, но теперь для страницы авторизации.

    Защита от роботов при попытке авторизации

    Защита от SPAM

    Вкладка Спам в комментариях

    Капчу в формах для комментариев я не активирую, так как не хочу усложнять комментирование. Терпеть не могу когда приходится выполнять целый квест, что-бы написать пару строчек. А вот блокировку спам-ботов от комментирования включаем обязательно.

    Сканнер

    Отслеживание изменений в файлах

    Конечно ставим галочку. Если защита wordpress плагина All In One WP Security все же пропустит хакера, то вы сможете узнать какие именно файлы изменил взломщик. Тогда вы сможете восстановить эти файлы из резервной копии.

    Отслеживание изменений в файлах

    Режим обслуживания

    Защиты сайту не прибавит, но позволит создать заглушку на время пока вы «ремонтируете» сайт, тогда посетители поймут, что сайт не сломан, а идут профилактические работы.

    Разное

    Здесь может быть полезным только одна вкладка — Защита от копирования. Включив эту опцию — на сайте нельзя будет выделить и скопировать текст.

    Защита от копирования текста

    Настройка плагина безопасности WordPress All In One WP Security завершена.
    Теперь самое время вернуться к пункту Панель управления и посмотреть, сколько балов показывает счетчик защиты.

    Мой сайт защищен на 290 балов

    Это был один из серии уроков про лучшие бесплатные плагины wordpress, так что подписывайся на новые статьи и читай только полезные уроки.
    Шутка дня:

    Если Вы проснулись на улице, значит Вы там заснули

    Базовая защита WordPress от вирусов и взлома

    CMS WordPress является хорошо защищенной системой, но в любой системе можно найти уязвимые места. Разработчики WordPress стараются сделать защиту CMS более надежной с каждым новым выпуском, но злоумышленники также не сидят сложа руки. Поэтому, для защиты своего сайта от взлома, вирусов и атак вам придется принимать некоторые меры самостоятельно.

    Я могу дать несколько практических советов по защите WordPress, которые помогут вам защитить WordPress сайт от базовых угроз, вирусов и атак.

    Основные меры по защите WordPress

    Защитить WordPress от базовых угроз не сложно, для этого достаточно предпринять некоторые меры. Для того, чтобы упростить поставленный задачи, я рекомендую воспользоваться плагином “Better WP Security”.

    После установки и активации плагина на WordPress, пройдите в админку сайта на страницу настроек “Better WP Security”, и создайте резервную копию базы данных, на всякий случай.

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

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

    Но то еще не все. После того как вы выполните первые требования плагина, перед вами откроется таблица, в которой будут указаны все потенциальные точки уязвимости вашего сайта. Для защиты вашего WordPress сайта необходимо исправить все недочеты в защите.

    Устранение уязвимостей WordPress

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

    Для примера, я взял стандартный незащищенный блог на WordPress. Давайте вместе устраним все известные нам уязвимости в WordPress.

    1. Проверка сложности пароля для всех пользователей

    Для того чтобы обеспечить сложными паролями всех пользователей, нужно исправить первую уязвимость. Пройдите по ссылке “Нажмите, чтобы исправить” и на открывшейся странице выберите пункт как на рисунке снизу “Strong Password Role – Subscriber”. Тем самым, пароли всех ваших пользователей будут проходить проверку сложности.

    2. Убираем дополнительную информацию из заголовка WordPress

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

    Для удаления подобной информации поставьте галочку в соответствующем поле.

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

    3. Скрываем обновления от не администраторов

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

    4. Поменять логин администратора

    Аккаунт администратора WordPress по умолчанию имеет логин admin, и об этом все знают. Поэтому ваш сайт взломать проще. Для того чтобы усложнить взлом сайта, рекомендую переименовать ваш администраторский аккаунт. Для этого перейдите по ссылке “Кликните здесь, чтобы переименовать администратора” и введите новое имя администратора в соответствующее поле.

    5. Поменяйте ID администратора

    Аккаунту администратора по умолчанию присваивается и >

    6. Поменять префикс таблиц базы данных WordPress

    По умочанию таблицы базы данных WordPress имеют префикс wp_. Рекомендуется поменять префикс на любой другой. Даже если ваша база данных уже наполнена информацией, то плагин better wp security поменяет префикс таблиц вашей базы без потери данных. Рекомендовано перед этим действием сделать резервную копию базы данных, что мы и сделали в самом начале.

    7. Спланируйте создание резервных копий

    Для регулярного создания резервной копии вашей базы данных, задайте некоторые условия и введите ваш e-mail, куда будут отправляться копии базы данных. Тем самым вы в любое время сможете восстановить базу данных из копии, при необходимости.

    8. Запретить доступ к админке в определенное время

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

    9. Заблокируйте подозрительные хосты

    Если вы знаете IP адреса подозрительных хостов, с которых может быть произведена атака на ваш сайт, то занесите эти IP адреса в бан лист, и доступ к сайту с этих IP будет закрыт.

    10. Защитить логин от перебора

    По умолчанию плагин защищает логин от перебора и после 3-х неудачных попыток блокирует IP адрес.

    11. Скрыть админку WordPress

    Этот пункт не является критическим, но все же будет полезно скрыть админку WordPress. Скрытие WordPress админки происходит путем переименования директории с админ панелью. Физически админ панель будет лежать в той же папке, но по адресу https://ваш_сайт.ru/wp-admin она будет недоступна.

    Скройте админ панель WordPress, для этого введите новые имена для директорий в соответствующие поля и поставьте галочку для включения данной опции.

    12. Защитить файл .htaccess и скрыть каталоги от просмотра

    Рекомендую вам скрыть каталоги сайта от свободного просмотра, а также защитить файл .htaccess. Также вы можете запретить выполнять различные запросы к сайту через адресную строку. Напоминаю, что данные действия могут вызвать конфликт с некоторыми плагинами и темами.

    18. Запрещаем запись файлов wp-config.php и .htaccess

    Некоторые пункты были по умолчанию выполнены, поэтому предлагаю вам выполнить наиболее важный 18 пункт защиты, который поможет запретить перезапись файлов wp-config.php и .htacces. Этот пункт очень важен, потому что от сохранности файлов wp-config.php и .htacces может зависеть работоспособность вашего сайта.

    20. Переименовать папку с содержимым wp-content

    Также вы можете переименовать папку с основным содержимым сайта wp-content. Нестандартное размещение файлов усложнит злоумышленникам доступ к ним.

    21. Установка безопасного соединения с WordPress

    Для работы с WordPress вы можете использовать безопасное соединение SSL, но для начала удостоверьтесь, что данный протокол поддерживается сервером, на котором размещается ваш сайт.

    Вот таким образом, с помощью плагина “better wp security” вы можете защитить WordPress от базовых угроз, вирусов и атак.

    WordPress XML-RPC-атака

    XML-RPC используется для Brute Force паролей

    Помимо фр Помимо проблем безопасности, упомянутых в других ответах, в атаках грубой силы против xmlrpc.php появился всплеск. Эти атаки пытаются получить пароли. Sucuri имеет хорошую документацию по этому вопросу.

    Это не ошибка в программном обеспечении. Реализация XML-RPC WP включает в себя процедуры аутентификации. Атакующие переключились на эту технику, поскольку она часто не блокируется различными плагинами грубой силы, и она быстрее.

    Если вы не используете службы, требующие XML-RPC, вы можете просто отключить их. Я рекомендую установить права доступа к файлам 000.

    Таким образом, вы можете легко вернуть изменение, если оно вызывает проблемы. Обратите внимание, что pingbacks используют xml-rpc, поэтому это приведет к поломке pingbacks, если вы включили их.

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

    Мы видели, что это действительно влияет на серверы, когда несколько сайтов попадают в одно и то же время, и/или хостинг-провайдеры используют CloudLinux для управления ресурсами для каждой учетной записи.

    Update:

    XML-RPC DOS вопрос или Brute Force?

    Кстати, у нас только что было предупреждение сервера о загрузке. В ходе расследования мы обнаружили, что сайт WP подвергся атаке. Я сделал немного дополнительного анализа и придумал эту проверку, чтобы определить, страдаете ли вы от проблемы с XML-RPC DOS или парольной атакой.

    Есть две четкие признаки XML-RPC DoS Exploit:

    • нескольких исходящих подключений к удаленным веб-сайтов.
    • Высокая скорость трафика xmlrpc.php

    С перебором, вы не увидите эти исходящие запросы на удаленный веб-сервер.

    Глядя на странице состояния Apache мы видим:

    7-0 17954 0/11/11 _ 0.96 2 16149 0.0 0.01 0.01 attacker.com localhost POST /xmlrpc.php HTTP/1.0 8-0 17962 0/10/10 _ 1.14 0 0 0.0 0.00 0.00 attacker.com localhost POST /xmlrpc.php HTTP/1.0 9-0 17968 0/10/10 _ 0.77 3 0 0.0 0.00 0.00 attacker.com localhost POST /xmlrpc.php HTTP/1.0

    localhost является хозяином под атакой.

    attacker.com – удаленная система наводнения в запросах до xmlrpc.php.

    Глядя на NetStat (IP-адрес протертый по причинам конфиденциальности):

    tcp 0 0 localhost:39254 remotehost:80 TIME_WAIT – tcp 0 0 localhost:39248 remotehost:80 TIME_WAIT – tcp 0 0 localhost:39251 remotehost:80 TIME_WAIT – tcp 0 0 localhost:39250 remotehost:80 TIME_WAIT – tcp 0 1 localhost:39260 remotehost:80 FIN_WAIT1 – tcp 0 0 localhost:39257 remotehost:80 TIME_WAIT – tcp 0 0 localhost:39258 remotehost:80 TIME_WAIT – tcp 0 0 localhost:39237 remotehost:80 TIME_WAIT –

    remotehost является жертвой атаки DoS.

    Как правило, ваш localhost не должен звонить на удаленный веб-сервер, если вы не используете какой-либо удаленный API. Даже тогда, когда сотни таких соединений очень подозрительны. Обратите внимание, что мы видели оба порта 80 и 443 под атакой.

    Чтобы подтвердить тип атаки, мы захватили часть трафика и нашел эту полезную нагрузку:

    POST /xmlrpc.php HTTP/1.0 Host: localhost Content-type: text/xml Content-length: 268 User-agent: Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0) Connection: close pingback.pinghttps://victim.comhttps://localhost/blog/just-another-post/

    В этом случае localhost был на самом деле IP-адрес, а не имя домена. Я не уверен, нужен ли IP для этой атаки, я бы так не подумал, но это будет означать, что вы устраните необходимость поиска DNS как для атаки, так и для сканирования.

    Sucuri имеет хорошую запись WP XMLRPC DoS attack также Incapsula.

    Плагин WordPress для защиты от брутфорс атак !

    Сегодня я покажу как защитить сайт на wordpress от брутфорс атак. Что это такое ? Брутфорс — это автоматические программы роботы, которые пытаются методом перебора паролей взломать ваш сайт. Такие программы не только могут взломать ваш сайт, они могут занести на ваш сайт вирус. К тому же такие автоматические программы, создают серьёзную нагрузку на базу данных, своими многочисленными запросами к файлу wp-login.php. Лучше поздно чем никогда, но советую вам заранее установить на ваш сайт защиту, как раз этим мы сейчас и займёмся, поехали !

    Плагин, которым мы будем защищаться, называется — Brute Force Login Protection. Плагин автоматически блокирует пользователя, который превысил лимит попыток входа в админ-панель. В настройках вы сможете установить количество попыток и время, на которое будет заблокирован пользователь. Хотелось бы отметить, что на странице входа будет отображаться количество оставшихся попыток, поэтому нормальные пользователи не будут блокироваться. Можно будет вручную блокировать и разблокировать ip-адреса. Установить данный плагин вы сможете прямо из админ-панели wordpress. Перейдите по вкладке: Плагины — Добавить новый , введите название плагина в форму поиска, нажмите Enter, установите и активируйте открывшийся плагин.

    Чтобы настроить плагин, перейдите по вкладке: Настройки — Brute Force Login Protection.

    На странице настроек, вверху, у вас должно отображаться — зелёная галочка и надпись — You are protected!, что обозначает, то что вы Защищены. И три зелёных галочки с надписями:

    .htaccess файл найден

    .htaccess файл читаемый

    .htaccess файл для записи

    В файле .htaccess, который расположен в корневом каталоге на хостинге, будет автоматически прописан специальный код, который и будет защищать ваш сайт. Разберём остальные настройки:

    Allowed login attempts before blocking IP, здесь нужно указать количество разрешённых попыток входа в админ-панель, после чего пользователь будет заблокирован. По умолчанию указано 20, но я считаю, что это слишком много, рекомендую указать 4-6 попыток. Нормальный пользователь после трёх попыток просто восстановит пароль и всё.

    Minutes before resetting login attempts count, укажите в минутах сколько будет длиться блокировка. Указывайте по больше, так как нормальным пользователям будет показано сколько у них осталось попыток для входа. А роботы пусть тусуются по дольше.

    Delay in seconds when a login attempt has failed (to slow down brute force attack), укажите задержку в секундах между неудачными попытками, для снижения нагрузки на сайт. 3-5 секунд я думаю нормально будет.

    Inform user about remaining login attempts on login page, информировать пользователя об оставшихся попыток входа в систему на странице входа. Очень полезная функция для нормальных пользователей. Ставьте галочку.

    Send email to administrator when an IP has been blocked, если поставите галочку, то при каждой блокировки, администратору сайта будет приходить письмо на email.

    Message to show to blocked users (leave empty for default message), оставьте поле пустым, здесь можно указать сообщение для заблокированных пользователей, не обязательно, роботы не умеют читать :-))

    .htaccess file location, здесь указан путь к файлу .htaccess

    В конце Сохраняем настройки — Save .

    Внизу страницы вы сможете вручную либо заблокировать, либо добавить в белый список ip-адрес. Просто добавьте в специальное поле ip-адрес и нажмите на кнопку рядом с полем.

    Blocked IPs, заблокировать IP адреса.

    Whitelisted IPs, одобрить, добавить в белый список.

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

    Мастер Йода рекомендует:  Unity опубликовала исходный код своего игрового движка и редактора
    Добавить комментарий