Вот почему существует интерфейс XML-RPC
Интерфейс является полезным инструментом для управления контентом. Он используется, чтобы позволить вам управлять веб-сайтом и писать статьи с помощью приложений для настольных компьютеров и смартфонов. Он также заботится об пингбэках. Pingback API обеспечивает тип «соединения» между блогами, в то же время это интерфейс, используемый для управления WordPress с помощью внешних программ. Поддерживается не только WordPress API, но и Blogger API, metaWeblog API, Movable Type API и Pingback API.
Однако большинству пользователей этот интерфейс не нужен, поскольку они пишут свои статьи непосредственно в WordPress. Кроме того, пингбеки других блогов не являются обязательными.
Почему xmlrpc.php представляет угрозу безопасности
Области, защищенные паролем, являются привлекательной целью. xmlrpc.php — один из них. По мере того, как все больше блоггеров защищают административную область своих веб-сайтов, злоумышленники теперь сосредотачиваются на интерфейсе управления и позволяют своим атакам грубой силы нацеливаться на него. Проблема в том, что атаки на интерфейс XML-RPC могут выполняться намного эффективнее, чем атаки на админку WordPress.
С помощью инструмента настройки один запрос к интерфейсу может охватывать невероятные 500 паролей. Файл позволяет злоумышленникам узнавать комбинации имен пользователей и паролей с помощью вызовов функций wp.getUsersBlogs или wp.getComments. Как только хакер отправит имя пользователя и пароль, xmlrpc.php ответит и сообщит, верна комбинация или нет.
Это делает взлом установки WordPress намного более эффективным и многообещающим. Это превращает в основном неиспользуемый интерфейс в серьезную угрозу безопасности, и поэтому его следует деактивировать как можно скорее. Другим, более общим преимуществом его отключения является повышение производительности веб-сайта.
Деактивация интерфейса XML-RPC
Начиная с версии WordPress 3.5 интерфейс XML-RPC активирован по умолчанию. Тогда его было очень легко деактивировать, а сегодня это возможно только обходными путями. Но обходные пути не слишком сложны. В целом, для отключения интерфейса и предотвращения доступа к нему необходимы три шага.
Часть первая: деактивация интерфейса с помощью фильтра
Следующий код нужно вставить в папку темы functions.php.
Щелчок по изображению открывает GitHub Gist
Теперь интерфейс полностью деактивирован. Однако он по-прежнему отображается в HTTP-заголовке веб-сайта.
Часть 2. Деактивация записи заголовка HTTP
Если он все еще отображается, к нему все еще можно получить доступ. Хотя это больше не может быть угрозой безопасности, это все же может повлиять на производительность веб-сайта. Вот почему запись должна быть удалена. Этот фрагмент кода также необходимо поместить в functions.php вашей темы. Здесь вы можете найти полный код с включенным фильтром из первой части:
Щелчок по изображению открывает GitHub Gist
Часть 3: Блокировка xmlrpc.php через .htaccess
Пока WordPress имеет доступ к xmlrpc.php, существует скрытый доступ к файлу. Это не влияет на производительность веб-сайта, поэтому файл должен быть снова заблокирован файлом .htaccess.
Важная вещь, прежде чем начать: пожалуйста, создавайте резервную копию файла всякий раз, когда вы изменяете .htaccess!
Одна ошибка при редактировании файла может привести к тому, что ваш сайт перестанет работать. Вы также должны иметь в виду, что из-за точки перед именем файла .htaccess рассматривается как системный файл в Mac OS X. Это приводит к тому, что файл не отображается, как только он находится на рабочем столе. Вы можете использовать терминал или виджет панели инструментов для поиска скрытых файлов.
Вставьте следующую запись в файл .htaccess в Основной индекс установки WordPress. Запись должна быть выше #Начать WordPress. Файл можно открыть и отредактировать с помощью текстового редактора, такого как Блокнот или TextEdit.
Основной индекс установки WordPress
Щелчок по изображению открывает GitHub Gist
Заключение
Эти три маленьких шага сделали ваш WordPress значительно безопаснее. Атака на xmlrpc.php теперь невозможна, и даже запросы к этому файлу больше не отвечают, что помогает с производительностью. Однако вы должны знать, что WordPress больше не получает пингбэки, и вы также больше не можете управлять своим контентом в приложениях любого типа. Однако это должно быть лишь небольшим недостатком, который не перевешивает выигрыш в безопасности.
(дпе)