Я потратил годы на оптимизацию сайтов WordPress, настройку MySQL, настройку конфигураций серверов и устранение узких мест в производительности. Но ничто не подготовило меня к открытию, которое я сделал, когда мой сервер начал плавиться из-за постоянной нагрузки на процессор в течение последнего месяца. Это не было увеличение трафика. Это был не неудачный плагин. Это был даже не плохой запрос в обычном смысле этого слова. Настоящим виновником оказалось то, чего я не ожидал: то, как WordPress перенаправляет кэш плагинов, совпадает.
На первый взгляд, кэширование результатов перенаправления кажется разумным. Если плагин перенаправления обнаруживает совпадение с шаблоном, зачем снова оценивать его для того же пути? При точном перенаправлении «один к одному» такое поведение безвредно и даже полезно. Но когда сайт атакован и вы все испортили LIKE или перенаправления в стиле регулярных выражений, кэширование перенаправлений становится настолько серьезной помехой, что может незаметно убить ресурсы вашего сервера.
Это история о том, как я обнаружил эту уязвимость, отслеживая проблемы с производительностью, начиная от скачков ЦП и заканчивая перегрузкой MySQL, а затем углубляясь в рост таблиц, который полностью вышел из-под контроля.
Содержание
Начинается коллапс
После перехода на FlyWP мой сервер работал быстрее, чем когда-либо, поэтому внезапное увеличение потребления ресурсов ЦП вызывало тревогу. MySQL постоянно был привязан к высоким нагрузкам, работники PHP стояли в очередях, и даже простая загрузка страниц казалась вялой. Перезапуск сервера дал мне кратковременное окно стабильности, но через несколько часов дела снова пошли плохо.
Что-то было в корне не так.
Я включил полную регистрацию запросов в надежде найти дорогостоящие соединения или неиндексированные запросы. Вместо этого возникла удивительная закономерность. Огромное количество запросов попадает в таблицу кэша перенаправлений, созданную плагинами перенаправления WordPress. Поначалу меня это не беспокоило — кэширование совпадений перенаправления — распространенный метод ускорения будущих запросов. Однако количество кэшированных записей было намного больше, чем мог оправдать обычный трафик.
Это привело меня в кроличью нору.
Отслеживание проблем в MySQL
Таблица кэша перенаправления была очень большой. Каждый раз, когда я проверял, там появлялись тысячи строк. При ближайшем рассмотрении выяснилось, почему: каждый раз, когда URL-адрес попадал на сервер, любое правило перенаправления использовало частичное совпадение.LIKE сравнения, шаблоны подстановочных знаков или регулярные выражения — плагин записывал результат как новую запись в кэше.
Хакеры и сканеры не пытались использовать некоторые URL-адреса. Они использовали тысячи перестановок на сайте:
/random-path
/random-path1
/random-path2
/admin-old
/admin-new
/login-old
/login-backupКаждый из этих путей вызывал новую реферальную оценку. При воспроизведении перенаправлений на основе модели плагину приходилось проводить дорогостоящие сравнения со своими правилами перенаправления. А поскольку он кэшировал каждую игру, таблица росла с каждым запросом, сделанным ботами, сканерами и инструментами грубой силы.
Чем больше становилась таблица, тем дороже становилось каждое сравнение. MySQL не мог идти в ногу со временем. Серверы не были перегружены легитимным трафиком. Этому препятствовала стоимость управления реферальными моделями.
Скрытые опасности отвлечения внимания на основе моделей
Все плагины перенаправления WordPress обещают гибкое сопоставление:
- Перенаправить все, что начинается с заданного пути
- Перенаправить все, что заканчивается определенной структурой
- Отклонение шаблонов с помощью подстановочных знаков
- Перенаправление с использованием полной поддержки регулярных выражений
Эти функции теоретически эффективны и безвредны на небольших сайтах. Опасность возникает только тогда, когда кэширование перенаправления и сопоставление шаблонов конфликтуют в масштабе.
Кэширование кажется хорошей практикой, и при точном перенаправлении это действительно так. Но когда LIKE операторов или шаблонов регулярных выражений, кеш становится бомбой замедленного действия. Сочетание мощной логики поиска, непрерывного сопоставления и неограниченного роста кэша означает, что решительному хакеру даже не нужно специально нацеливать перенаправления. Исследования путей по всему вашему сайту достаточно, чтобы привести к сбою вашего сервера.
Проверка большего количества URL-адресов создает больше строк кэша. По мере создания большего количества строк каждое новое сравнение становится медленнее. Поскольку сравнения замедляются, загрузка ЦП увеличивается. В конце концов MySQL перегружается, потоки PHP останавливаются, и вся архитектура начинает перегружаться.
Это не недостаток одного плагина. Следующие плагины перенаправления WordPress работают, когда включено сложное соответствие.
Нахождение основной причины
После того как я сопоставил нагрузку запроса с производительностью кэша перенаправления, я напрямую проверил таблицу кэша. Он стал настолько большим, что даже основные операции выполнялись медленно. Нередко в короткое окно добавлялись тысячи строк. Каждый сканер, сканер и бот, выбравший неожиданный путь, добавлял больше записей.
На этом этапе уязвимость стала очевидна: плагины перенаправления WordPress непреднамеренно позволяют злоумышленникам генерировать экспоненциальные затраты путем тестирования большого количества URL-адресов. Им не нужны действительные пути. Им не нужно взламывать систему. Им просто нужно заставить работать логику перенаправления.
Остальное сделал механизм перенаправления.
Коррекция
Как только я понял механику, решение пришло быстро. Хотя имя таблицы варьируется от плагина к плагину, каждый плагин перенаправления поддерживает аналогичный кеш. В этом случае я использую Rank Math для своих примеров ниже.
- Удалите все LIKE и перенаправления в стиле регулярных выражений.: любое правило перенаправления, использующее сопоставление на основе шаблона, должно быть отключено. Активам разрешалось оставаться только для точного перенаправления один к одному. Поскольку администратор был отзывчивым, мне пришлось сделать это, используя запрос UPDATE непосредственно в моей базе данных.
UPDATE wp_rank_math_redirections
SET status="inactive"
WHERE sources NOT LIKE '%"comparison":"exact"%';- Усечь таблицу кэша перенаправления: Очистка стола убрала большое количество сохраненных игр:
TRUNCATE TABLE wp_rank_math_redirections_cache;- Мониторинг сервера после очистки: Загрузка процессора упала практически мгновенно. MySQL стабилизировался. Сотрудники PHP возобновили нормальную работу. Бурный рост прекратился.
Точные перенаправления работали именно так, как предполагалось. Без подстановочных знаков или перенаправления регулярных выражений ни одна атака не сможет заставить кэш вырасти.
Что это значит для пользователей WordPress
Плагины перенаправления WordPress не являются небезопасными в традиционном смысле этого слова. Но у них есть общая архитектурная уязвимость: кэширование результатов перенаправления полезно только в том случае, если перенаправление является точным. После реализации сопоставления с образцом кэширование становится опасным, поскольку каждый неизвестный URL-адрес становится новой записью в кэше.
На сайте с высоким трафиком или интенсивно сканируемым сайтом это означает:
- Рост стола становится неограниченным
- MySQL становится перегруженным
- Спираль использования ЦП
- Сервер замедляется или выходит из строя
Лучшая защита проста:
- Никогда не полагайтесь на подстановочные знаки или перенаправление регулярных выражений в WordPress.
- По возможности сохраняйте точность логики перенаправления.
- Передавайте сложные правила перенаправления на пограничный уровень NGINX или CDN.
- Периодически проверяйте или очищайте таблицы кэша перенаправления.
Кэш перенаправления полезен при использовании с простыми и точными правилами. Но как только сайт использует автоматическое тестирование и у вас есть перенаправление на основе модели, этот же механизм кэширования становится помехой, которая может снизить производительность сервера.
Я усвоил это на собственном горьком опыте. Надеюсь, это поможет кому-то еще избежать той же ловушки.
