У многих владельцев WordPress есть опасная мысль: «Ну пароль же сложный, значит все нормально». Не совсем. Если бот уже знает ваш логин админа, ему остается только долбить пароль, искать утечки, пробовать старые комбинации или атаковать через зараженный браузер. И одна из самых скучных, но рабочих лазеек — перечисление пользователей через REST API.
Звучит занудно. На деле все просто: сайт сам может подсказать, какие юзеры у него есть. А значит — какие логины стоит атаковать в первую очередь. И да, это касается не только больших проектов. Маленький магазин на WooCommerce, сайт салона, корпоративный сайт на 12 страниц — вообще без разницы. Боты не выбирают «интересные» сайты. Они пылесосят все подряд. Кстати, вот тут это хорошо разобрано: как хакеры вообще находят ваш сайт.
Что вообще такое перечисление пользователей
Если по-простому — это способ узнать, какие пользователи есть на сайте, без входа в админку. В WordPress для этого часто дергают REST API, обычно по адресу вроде /wp-json/wp/v2/users. Если сайт отдает список пользователей, бот видит имена, slug, иногда отображаемые имена, а иногда и другие куски инфы.
И вот тут начинается неприятное. Потому что username и display name у многих совпадают. Или slug совпадает с логином. Или админ называется admin. Ну камон.
Сам по себе REST API не «дырка» в классическом смысле. Он нужен теме, плагинам, редактору Gutenberg и куче нормальных функций. Но если сайт отдает лишнее — это уже подарок для атакующего.
Почему это опасно именно для малого бизнеса
Потому что у малого бизнеса часто все держится на одном человеке. Один админ. Один менеджер. Один сайт. Один пароль менеджер еще и от почты помнит в блокноте. Если бот узнает логин администратора, он может:
- запустить brute-force атаку на вход
- проверить логин против старых утекших паролей
- подобрать пароль к почте, если логин похож на email
- использовать имя юзера в фишинговом письме — а такие письма выглядят куда убедительнее
И да, многие взломы начинаются не с «супер-хакерской магии», а с банального знания логина и слабого пароля. Если тема вам знакома, почитайте еще про слабые пароли и как из-за них уводят сайты. Там как раз про реальную, приземленную боль.
Как боты это делают на практике
Очень тупо. И очень быстро.
Бот проходит по списку сайтов и проверяет стандартные адреса. Не только REST API, кстати. Еще авторские архивы, sitemap, страницы комментариев, старые RSS, форму восстановления пароля. Но REST API — один из самых удобных вариантов, потому что он машинно читаемый. Скрипту не надо ничего «понимать глазами». Получил JSON, вытащил имена, пошел дальше.
Примерный сценарий такой:
- Бот открывает
/wp-json/wp/v2/users - Если видит ответ — сохраняет список пользователей
- Ищет среди них admin, editor, shopmanager или похожие имена
- Потом бьет в
/wp-login.phpили XML-RPC
На все это уходят секунды. Даже не минуты.
Причем вы можете вообще ничего не заметить. Сайт работает. Заказы приходят. А в логах уже десять тысяч запросов на вход. Вот поэтому базовая защита входа в систему — не «доп опция», а вещь из разряда must have. Особенно если у вас есть админ, редактор и менеджер магазина.
Как проверить, видны ли пользователи на вашем сайте
Проверка простая, можно сделать самому за 2 минуты.
Откройте в браузере:
вашсайт.ру/wp-json/wp/v2/users
Если видите JSON со списком людей — значит, перечисление работает. Иногда список отдается не всем, а только частично. Иногда виден только slug. Но и этого бывает хватит.
Еще можно проверить адреса вида:
вашсайт.ру/?author=1
Если вас перебрасывает на страницу автора, и в URL видно имя юзера — тоже плохо. Не смертельно, но плохо.
Честно говоря, большинству владельцев сайтов не надо ковыряться глубже. Если список пользователей снаружи виден — это уже повод закрыть вопрос.
Что делать — без паранойи, но по делу
Самая частая ошибка — взять и целиком отключить REST API. Плохая идея. После этого иногда отваливается редактор, интеграции, мобильные приложения, некоторые плагины. Видел как из-за этого сайт лег насмерть после «совета из форума».
Нормальный путь такой:
- закрыть публичный доступ к endpoint пользователей
- убрать предсказуемые логины вроде admin
- включить лимит попыток входа
- отключить то, чем не пользуетесь, например XML-RPC
- добавить 2FA для админов
Вот это уже работает в реальной жизни.
Если делать руками, специалисту на это нужно примерно 20-40 минут на обычном сайте. По деньгам — часто это либо входит в нормальное обслуживание, либо стоит как разовая мелкая настройка. Не сотни евро, короче. Если у вас сайт живой и на нем идут заявки или продажи, логичнее держать такие вещи в рамках регулярного обслуживания WordPress, а не вспоминать о безопасности после взлома.
Какие меры реально помогают
Давайте без магии. Вот что дает эффект.
1. Не использовать логин admin
Да, звучит банально. Но до сих пор куча сайтов живет с админом admin, administrator или именем компании. Если логин уже известен, вы теряете половину защиты паролем.
Лучше создать нового администратора с непредсказуемым логином. Старого — удалить или понизить в правах. На это уходит минут 10.
2. Закрыть endpoint с пользователями
Не весь REST API, а только то что сливает список юзеров наружу. Это делается кодом, через плагин безопасности или через правила доступа. Для малого бизнеса это самый разумный компромисс — сайт работает как раньше, а лишняя инфа наружу не торчит.
3. Включить двухфакторку
Даже если логин узнали, одного пароля уже мало. И это, наверно, лучший апгрейд безопасности по соотношению «5 минут настройки / куча пользы».
4. Ограничить попытки входа
Если бот стучится 500 раз в час, сайт должен сказать «хватит». Блокировка по IP, капча, задержка, логирование — все это резко режет мусорный трафик.
5. Следить за подозрительными юзерами и изменениями
Иногда проблема всплывает поздно — когда на сайте уже появился левый админ. Вот почему журнал действий, мониторинг файлов и обычные уведомления по безопасности полезнее, чем очередной «ускоритель сайта» с сомнительной фишкой.
А если логины уже утекли — все, поздно?
Не-а.
Если ваш сайт уже светит пользователей через REST API, это неприятно, но не катастрофа. Просто закройте дыру и усилите вход. А вот если вы уже видите странные входы, новых админов, редиректы на казино, мусорные страницы в индексе Google — тогда история другая. Тут уже надо не «подкрутить безопасность», а разбираться со взломом и чисткой. Потому что бэкдор мог остаться в файлах, а вы его глазами не найдете.
Если есть подозрение на взлом, не тяните. Тут нужна уже нормальная помощь после взлома сайта, а не надежда, что «само пройдет». Само не пройдет, чо уж.
Коротко — что стоит сделать сегодня
Если у вас WordPress-сайт компании, магазина или услуг, начните с этого:
- Проверьте
/wp-json/wp/v2/users - Убедитесь, что у вас нет логина admin
- Включите защиту входа и 2FA
- Ограничьте доступ к списку пользователей
- Посмотрите логи входов хотя бы за последние 7 дней
Все. Этого уже хватит чтобы срезать большой кусок тупых автоматических атак.
И да, не надо превращать маленький сайт в бункер за бешеные деньги. Для сайта кофейни, стоматологии или интернет-магазина на 200 товаров хватит нормальной базовой защиты, апдейтов и мониторинга. Но вот игнорировать такие мелочи как перечисление пользователей — тоже не стоит. Именно из таких «мелочей» потом и складывается взлом.
Короче: если бот знает ваш логин, вы уже в менее выгодной позиции. Не давайте ему этот подарок.