Блог

RSS-feed блога на WordPress при включенной защите от сетевых атак на хостинге

Некоторое предисловие

Простая задача по поддержанию блога на собственном хостинге подчас перестает быть такой простой, как казалось на первый взгляд. Так, приходится выбирать между функционалом и безопасностью, между быстродействием и оформлением. Так, начав свой путь в поддержании блога на WordPress-движке с 50 плагинов-расширений, я перешел на 5 самых необходимых, без которых трудно обойтись, дописав весь нужный функционал в сам код темы. Так, с использования тем со встроенными фичами я пришел к созданию child-тем, добавляя каждую новую функцию и элементы оформления только по необходимости. Слишком много лазеек оставляют расширения, слишком много ресурсов забирают дополнения. Поэтому, если делать блог самому — это труд. Не тяжелый, и тут не надо иметь семь пядей во лбу. Но он должен быть вдумчивый, последовательный и кропотливый.

И вот, вроде бы, когда у тебя уже полностью собранный под тебя продукт, который тебя устраивает на 120%, появляется какая-нибудь информация о том, что у тебя что-то не работает и хотелось бы, чтобы всё-таки работало. Эти вещи каждый раз разные по объему, по трудности, и они никогда не повторяются даже близко.

И вот, после непродолжительного счастливого владения своим продуктом, вдруг появились они — вездесущие сканеры уязвимостей, тотальная регистрация ботов в системе, попытки захватить контроль над админкой, используя слабые места файловой системы хостера… В общем, в какой-то момент эта борьба с ветряными мельницами начинает надоедать. И вместо ежедневного добавления в access deny подсетей бот-ферм, ты хочешь найти кое-что более простое и в то же время лучшее. Хорошо, что сейчас куча инструментов против бот-ферм. И, конечно, первое, что приходит в голову — защита от сетевых атак вроде CloudFlare. У моего хостера подобный инструмент есть. Подключаем. Думаем, что всё под контролем, но… всегда есть это но.

Вновь включенная защита от сетевых атак действует по принципу проверки клиента-посетителя на вшивость и проверки на всё и вся. Сначала клиент загружает незаметно быстро JavaScript, который, если всё хорошо, потом уже говорит браузеру, где взять нормальный контент. Это же хорошо? Да! Когда оно там как-то работает без тебя, не мешает тебе и твоим читателям. А когда оно начинает мешать? Отключать? А бот-фермы? Не отключать? А читатели?

В общем, этот метод проверки приложил rss-feed этого блога. Потому что на первый же запрос он любому rss-клиенту (да и валидатору) отвечал HTML/Text, на что тот обижался.

Как-то отдельно страницы выключить из работы защитника мне не удалось, поэтому пришлось поискать нестандартное решение. И оно нашлось. Необходимо просто-напросто выкладывать rss-ленту на другом домене.

Проблема с RSS: как её решить

Пример именно моей проблемы

Я столкнулся с этой проблемой на сайте. Стандартный фид WordPress по адресу https://brmx.ru/feed/ отдавал внешним валидаторам HTML-страницу с JavaScript-проверкой и cookie. Браузер проходил эту проверку, а валидаторы и клиенты rss не могли выполнить JavaScript, поэтому видели обычную веб-страницу.

Решение

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

Для решения проблемы был создан отдельный субдомен https://rss.brmx.ru и на нем опубликован PHP-скрипт по адресу /rss.php, который формирует RSS напрямую через WordPress, в обход нашей системы защиты.

Логика проделанного

1. Создаем отдельный субдомен rss.anyrandomdomain.ru для самостоятельной выдачи RSS без проблемной защиты основного сайта.
2. На субдомене размещаем PHP-скрипт, который подключает WordPress через wp-load.php, получает опубликованные записи и формирует RSS 2.0 (тут важно, чтобы скрипт работал в том же файловой системе на стороне сервера, и имел к папке установки wordpress необходимый доступ).
3. В процессе настраиваем путь к WordPress и следим чтобы версия PHP на субдомене была такой же, как и на основном домене.
4. Скрипт именуем как угодно (у меня — это rss.php) только не index.php, чтобы избежать обработки адреса как главной страницы основного сайта.

Резюме

Рабочий адрес RSS у моего сайта теперь такой: https://rss.brmx.ru/rss.php (ссылка на фид в самом низу каждой страницы этого сайта).

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