Disallow xmlrpc php: Правильный файл robots.txt для WordPress — важные правила при запрете индексации – Файл robots.txt для WordPress: для Яндекс и Google

И опять атака на сайты WordPress — перебор + XMLRPC / Habr

С полудня субботы на моем сервере, где хостится около 25 сайтов на WordPress, начались дикие тормоза. Так как мне удалось пережить предыдущие атаки (атака 1 — ровно год назад, атака 2 — в марте) не замеченными, то я не сразу понял, в чем дело.

Когда разобрался, то выяснилось, что идет перебор паролей + множество запросов к XMLRPC.

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

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

1. Останавливаем перебор, плагин Limit Login Attempts — ставим именно его, так как другие защиты сильно подвешивают сервер, например, при использовании плагина Login Security Solution сервер умер через полчаса, плагин сильно грузит базу.

В настройке обязательно включите галочку «За прокси» — иначе он будет для всех определять ip вашего сервера и автоматически блокировать всех.
UPDATE, спасибо DarkByte, подробности ниже в комментах — галочку «За прокси» включаем только если не работает определение при включенном «Прямое подключение»

2. Отключаем XML-RPC — плагин Disable XML-RPC (его просто активировать и всё).

3. Закрываем wp-login.php — если обращаться к сайту через ip, то плагин не срабатывает и подборщики продолжают долбить сайт. Чтобы этого избежать, в .htaccess добавляем:

Order Deny,Allow
Deny from all

Файл wp-login копируем, переименовываем в любое странное имя, например poletnormalny.php и внутри файла автозаменой меняем все надписи wp-login.php на poletnormalny.php.
Все, теперь к админке можно обратиться только по вашему файлу.

После этих 3 несложных шагов сайты опять начали летать и пришло спокойствие.

Ну и вдруг интересно

Один из вариантов как посмотреть, что вас атакуют. Это можно увидеть в логах nginx (например, вот путь для Debian /var/log/nginx файл access.log).

Если идет перебор, то вы увидите множество строк вида:

87.230.87.xx — — [04/Aug/2014:06:35:53 +0400] «POST /wp-login.php HTTP/1.0» 200 5791 «-» «-«

Запросы XMLRPC:
95.0.83.xx — — [04/Aug/2014:06:48:03 +0400] «POST /xmlrpc.php HTTP/1.0» 499 0 «-» «Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)»

Как отключить XML-RPC в WordPress

Для тех, кто не знает, что такое XML-RPC — это WordPress API, позволяющий (удалённо) выводить, создавать, редактировать и удалять:

• посты,
• таксономии (рубрики, метки и прочее),
• медиафайлы,
• комментарии,
• пользователей.

А также получать доступ к настройкам и изменять их.

Именно благодаря этому API работают различные приложения для iPhone, iPad и устройств на Android.

Так вот, в предыдущих версиях WordPress была вот такая штука в настройках:

Как известно, от «атома» WordPress отказался полностью, а протокол XML-RPC теперь установлен включенным по умолчанию.

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

Для параноиков (я и сам такой) — чтобы отключить XML-RPC, вставляем этот код в functions.php:

add_filter('xmlrpc_enabled', '__return_false');

Мне вот например не приходится пользоваться приложениями для iOS или Android, я пробовал конечно — ну вообще не понравилось, так что этот протокол мне ни к чему.

Удаляем метатеги с xmlrpc.php из head сайта

Насколько я знаю, существует два метатега: (RSD) и .

Первый удаляется достаточно просто — хуком на wp_head. Чтобы удалить второй, вам скорее всего придётся открыть файл

header.php в вашей теме wp и вручную удалить его из HTML-кода.

В теме вашего сайта этих тегов может и не быть.

Миша

В последние годы я долго не знал, что мне делать с сайтом misha.blog, ведь он практически не приносит никакого профита, но недавно я осознал, что моя миссия – способствовать распространению WordPress. Ведь WordPress – это лучший движок для разработки сайтов – как для тех, кто готов использовать заложенную структуру этой CMS, так и для тех, кто предпочитает headless решения.

Сам же я впервые познакомился с WordPress в 2009 году. Организатор WordCamp. Преподаватель в школах Epic Skills и LoftSchool.

Если вам нужна помощь с вашим сайтом или может даже разработка с нуля на WordPress / WooCommerce — пишите. Я и моя команда сделаем вам всё на лучшем уровне.

Что такое Xmlrpc.php для WordPress и как его отключить

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

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

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

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

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

Как проверить, включен ли XML-RPC на вашем сайте

Проверить можно с помощью XML-RPC Validator. Для этого:

1. 1. Перейдите на сайт XML-RPC Validator.
2. 2.

   В поле Address введите ваш домен и нажмите Check:

3. 3.
   Если вы получили сообщение «Congratulation! Your site passed the first check», то xmlrpc.php на вашем сайте включен.

   Если ответ «Failed to check your site at http://domain.ru because of the following error», то xmlrpc.php отключен.

Чтобы отключить XML-RPC выберите нужную инструкцию:

Отключить с помощью плагина

Отключить вручную

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

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

Если вы хотите сделать все вручную без установки плагина:

1. 1. Перейдите в корневую папку вашего сайта на WordPress: Как узнать корневую папку сайта?
2. 2.

   Откройте или создайте (если он отсутствует) файл .htaccess и вставьте в конце файла строки:

           
   order deny,allow
   deny from all
   
       

3. 3.

   Сохраните изменения.

После отключения XML-RPC доступ через xmlrpc.php будет закрыт. Тем самым вы дополнительно обезопасите свой сайт и сможете избежать блокировки услуги хостинга из-за нагрузки на CPU.

Помогла ли вам статья?

19 раз уже
помогла

Под прессом. Ломаем и защищаем WordPress своими руками / Журнал Хакер corporate blog / Habr

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/
/wp-content/languages/plugins
/wp-content/languages/themes
/wp-content/plugins/
/wp-content/themes/
/wp-content/uploads/

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

User-Agent: *
Disallow: /cgi-bin
Disallow: /wp-login.php
Disallow: /wp-admin/
Disallow: /wp-includes/
Disallow: /wp-content/
Disallow: /wp-content/plugins/
Disallow: /wp-content/themes/
Disallow: /?author=*
Allow: /

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

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

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

1. Найти в исходном коде страницы. Она указана в метатеге generator: /> или же в тегах : .
2. Найти в файле readme.html (рис. 1), который входит в состав установочного пакета и находится в корне сайта. Файл может иметь и другие названия типа readme-ja.html.
3. Найти в файле ru_RU.po (рис. 2), который входит в состав установочного пакета и расположен по адресу /wp-content/languages/: «Project-Id-Version: WordPress 4.1.1\n».

Рис. 1. Версия WordPress в файле readme.html

Рис. 2. Подсматриваем версию WordPress в файле ru_RU.po

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

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

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

Nmap:

— определение версии и темы с помощью скрипта http-wordpress-info

nmap -sV --script http-wordpress-info 

— подбор пароля по словарям

nmap -p80 --script http-wordpress-brute --script-args 'userdb=users.txt,passdb=passwords.txt' example.com

Metasploit:

— модуль для определения версии: auxiliary/scanner/http/wordpress_scanner;
— модуль для определения имени пользователя auxiliary/scanner/http/wordpress_login_enum.

WPScan:

— перечисление установленных плагинов: 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. Перебирая числа, ты и определишь имена пользователей

Получение контроля над WordPress с помощью использования XML-RPC

WordPress не стал самой популярной платформой на планете для CMS и размещения блога, потому что он является довольно сложным в использовании. Скорее всего, его удобный и богатый набор функций привлек около 70 миллионов вебсайтов и это только количество блогов, размещенных на WordPress.com

Это заинтересует вас:

Сегодня, нас интересует использование платформой

Скрыто от гостей

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

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

Эта уязвимость впервые

Скрыто от гостей

в сентябре 2015 года, и является одной из многих прошедших через XML-RPC. WordPress быстро

Скрыто от гостей

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

Step 1 Тестирование на наличие уязвимости

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

Вы можете просто проверить свой сайт на наличие файла /xmlrpc.php, как сделал я выше на своем локальном WordPress (замените «localhost» на URL вашего вебсайта). Если XML-RPC прослушивается, или находится там, вам сообщат об этом. Похоже, что мы нашли потенциально уязвимый блог (вам сообщат «forbidden» или что-то на подобие).

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

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

Код:

admin
MyPassword

Когда вы пытаетесь войти в WordPress, ваши имя пользователя/пароли отслеживаются следующим образом:

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

Это все, что я хотел рассказать в этом разделе.

Step 2 Взлом сервера

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

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

Скрыто от гостей

на GitHub и скачайте файлы через HTTP ссылку (Скачайте ZIP, или Git если вы зарегистрированы в нем.)

Откройте окно терминала и перейдите в директорию, в которую вы сохранили скачанный файл, затем разархивируйте его в следующее место:

Код:

unzip WordPress-XMLRPC-Brute-Force-Exploit-master.zip

Затем перейдите в этот каталог:

Код:

cd WordPress-XMLRPC-Brute-Force-Exploit-master

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

Код:

chmod 755 wordpress-xmlrpc-brute.py

Теперь запустите Python команду отдельно, и проверьте инструкции.

Код:

./wordpress-xmlrpc-brute.py

Я выделил инструкцию голубым цветом. Для локального хоста это:

Код:

./wordpress-xmlrpc-brute.py http://localhost/xmlrpc.php passwords.txt username

Необходимо соблюсти вышеуказанный порядок, а именно, имя Python файла, затем имя сервера, затем имя файла с паролем и, наконец, имя пользователя. Здесь мы используем файл passwords.txt, который включает в себя скачанный файл GitHub (который включает в себя небольшое количество паролей), и мы будем использовать admin, как имя пользователя. Если вы хотите использовать свой собственный список паролей, просто включите его в команду, вместо предыдущего, и используйте имя пользователя, которое считаете подходящим – этот инструмент работает только с паролями.

Так что, когда вы произведете указанные выше действия, используя имя вашего целевого сервера вместо «localhost,» ваш файл пароля и ваше имя пользователя, Python скрипт пропустит их через включенный файл passwords.txt и запустится в большей мере не обнаруженным способом. Если все прошло успешно, скрипт выдаст ваш логин в форме имя пользователя/пароль.

Как защититься от этого эксплойта

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

Скрыто от гостей

, и приложения для смартфонов типа

Скрыто от гостей

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

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