Журнал входов в админку: как читать и что отключить, пока не взломали

Журнал входов в админку — первое, что просят показать после взлома, и первое, чего на сайте нет. Ядро WordPress такой журнал не ведёт: ни в «Пользователях», ни в «Инструментах» нет раздела, где видно, кто и когда заходил под каким логином. Пока это не выяснено, владелец живёт с ощущением контроля: пароль сложный — значит, всё под присмотром.

Ниже — откуда журнал берётся, как по коду ответа сервера отличить перебор пароля от состоявшегося входа, какие плагины пишут историю действий, что отключить в WordPress и в каком порядке действовать в первый час после чужого входа. Отдельно скажу, чего делать не надо: популярная мера «спрятать страницу входа» ломает больше, чем защищает.

Почему журнала нет в админке и чем это заканчивается

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

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

Четыре источника журнала и границы каждого

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

Источник	Что видно	Чего не видно
Журнал обращений сервера (access.log)	каждый запрос: адрес, время, метод и путь, код ответа, браузер	логин: он в теле запроса, а тело не пишется
Журнал ошибок сервера (error.log)	сбои: следы вставленного кода, обращения к отсутствующим файлам	входы вообще
Плагин журналирования	входы с логином, попытки, создание пользователей, правки записей, активацию плагинов	всё до его установки; записи удаляются изнутри админки
Письма плагина безопасности	событие в момент, когда оно произошло	то, что не включено в настройках
Метаданные пользователей в базе	адрес, браузер и время входа по действующим сессиям	историю: закрытая сессия следа не оставляет
Панель хостинга	доступ к журналам, входы в саму панель и в FTP	глубину: хранение от нескольких дней до пары недель

Отсюда правило дороже прочих: журналы сервера ротируются. Появилось подозрение — скачивайте сегодня, разбирайтесь потом; искать их в панели хостинга в разделе «Журналы».

Как устроена строка журнала и что в ней читать

Одна строка — один запрос. Полей семь: адрес, дата и время с часовым поясом, метод и путь, код ответа, объём, страница-источник и браузер. Для разговора о входах хватает трёх: путь, метод, код.

Метод GET значит «отдай страницу», POST — «прими данные». Поэтому GET /wp-login.php — страницу входа просто открыли, таких запросов десятки в сутки; POST /wp-login.php — форма отправлена, то есть попытка войти.

Дальше решает код ответа. Пароль не подошёл — WordPress перерисовывает страницу входа с ошибкой, сервер отвечает кодом 200. Пароль подошёл — выставляются куки, браузер уходит в админку, код 302. Значит, 302 в ответ на отправку формы с незнакомого адреса — инцидент, а не подозрение.

Правило не абсолютное: кэш и файрвол меняют коды по-своему, поэтому войдите один раз сами и найдите свою строку — будет эталон. Ещё три кода: 403 — запрос отбит, 404 — файла нет (сотни таких строк к файлам плагинов означают сканер), 500 — сайт упал.

В самой записи смотрите шесть признаков: время (сверяясь с часовым поясом сервера), адрес (свой домашний и офисный стоит однажды записать; мобильный меняет адрес постоянно, а дата-центр или чужая страна — повод насторожиться), логин, результат, браузер и частоту. Пять попыток с вашим логином за месяц опаснее сотни в минуту с чужими.

Записи, по которым видно разведку, перебор и взлом

Смотреть надо в обратном порядке относительно интуиции: неудачных попыток сотни в сутки, это фон. Инцидент — один успешный вход, поэтому сначала ищите код 302.

Что видно в журнале	Что означает	Что делать сейчас
Сотни отправок формы входа с одного адреса, код 200	перебор, пароль не подошёл	заблокировать адрес, включить лимит попыток
Отправки с сотен адресов, по одной-две	перебор ботнетом, список не догнать	лимит попыток по логину, второй фактор
Логины admin, administrator, название сайта, домен	словарь, ваш логин не известен	проверить, что таких пользователей нет
Неудачные попытки с ВАШИМ логином	логин выяснили, остался пароль	второй фактор, закрыть список пользователей
Успешный вход (302) с незнакомого адреса	доступ получен, это взлом	весь порядок первого часа
Успешный вход ночью, когда вы спали	то же самое	пароли, соли, проверка пользователей
Массовые обращения к xmlrpc.php	метод system.multicall проверяет много паролей одним запросом	отключить, если не нужен
Запрос к /wp-json/wp/v2/users	сбор логинов: отдаются имена и слаги авторов	закрыть выдачу списка
Череда запросов вида /?author=1	подбор логина через архив автора	слаг автора сделать не равным логину
Создание нового пользователя	закрепление доступа	удалить, сменить соли
Смена пароля администратора без вас	вас отключают от сайта	восстановление через базу, дальше первый час
Активация незнакомого плагина	код оформили плагином	отключить, удалить файлы
Правка файлов темы из админки	вписывают чужой код в живой сайт	запретить редактор файлов

Признаки ботнета: десятки адресов из одних подсетей, одинаковая строка браузера у всех, отсутствие запросов к стилям и картинкам и заход строго на форму входа без просмотра сайта.

Плагины, которые действительно ведут журнал

Смотреть надо на три вещи: пишет плагин только входы или все действия, блокирует ли и сколько стоит по скорости.

Плагин	Что пишет	Блокирует	Нагрузка
Simple History	входы и попытки, правки записей, изменения настроек, действия с плагинами	нет	небольшая
WP Activity Log	почти всё: профили, роли, файлы, меню, метаданные	нет	заметная, таблица растёт быстро
Wordfence Security	Live Traffic — трафик в реальном времени; Login Security — второй фактор и лимит попыток	да, файрвол	высокая
All In One WP Security & Firewall	неудачные попытки, активность учётных записей, заблокированные адреса — три раздела меню	да	средняя
Sucuri Security	события, отчёт о последних входах, целостность файлов ядра	частично	средняя
Limit Login Attempts Reloaded	только попытки входа	да	минимальная
Two Factor	журнала нет, добавляет второй фактор	нет	минимальная
WP 2FA	то же плюс требование второго фактора по ролям	нет	минимальная

Предупреждение важнее выбора: два плагина безопасности одновременно ставить нельзя — они дублируют правила в .htaccess, блокируют по разным логикам и вдвоём грузят сайт. Визитке хватает лимита попыток и второго фактора; журнал действий нужен там, где над сайтом работают несколько человек, а тяжёлый комбайн — если есть кому разбирать его оповещения.

Что отключить и что за это сломается

Смысл не в закручивании гаек, а в том, чтобы убрать возможности, которыми вы не пользуетесь: каждая — лишняя дверь. Но цену надо знать заранее.

Что отключить	Что даёт	Что может сломать
Интерфейс xmlrpc.php — фильтром xmlrpc_enabled или запретом файла	убирает канал, где пароли проверяют пачками	приложение WordPress, Jetpack, внешние публикаторы
Выдачу списка пользователей по адресу /wp-json/wp/v2/users	логины авторов не отдаются одним запросом	редко — плагины, которым нужен список авторов
Совпадение логина и публичного имени автора	из архива автора логин не прочитать	ничего, самая безболезненная мера
Логин admin: новый администратор, старого удалить	половина словарей перебора бесполезна	ничего, если передать записи новому
Редактор файлов темы — DISALLOW_FILE_EDIT в wp-config.php	снимает правку кода из браузера под чужой сессией	файлы правятся только по FTP или через панель
Установку плагинов из админки — DISALLOW_FILE_MODS	чужой плагин из браузера не поставить	обновления вручную, а про них забывают
Показ ошибок — WP_DEBUG_DISPLAY в значение «ложь»	посетитель не видит пути на диске и версии	ничего, если ошибки пишутся в файл
Лишних администраторов	меньше записей и паролей, которые утекают	редактор потеряет настройки и плагины
Неограниченное число попыток входа	перебор становится бессмысленно медленным	можно запереть себя, нужен доступ по FTP
Вход по одному паролю: второй фактор администраторам	утёкший пароль сам по себе доступа не даёт	потеря телефона = потеря доступа, нужны резервные коды
Старые секретные ключи и соли в wp-config.php	обнуляет все сессии, включая чужую	всех выбросит из админки, включая вас
Доступ к wp-login.php с любых адресов	перебор не доходит до WordPress, нагрузки нет	при динамическом адресе запретесь сами

Логин admin штатно переименовать нельзя, поле не редактируется. Порядок — создать второго администратора, войти под ним, проверить права и удалить старого, приняв предложение передать его записи.

Соли — длинные случайные строки в wp-config.php, из которых считаются куки авторизации. Пока они прежние, чужая сессия действительна даже после смены пароля: человек просто продолжает сидеть в админке.

Чего делать не надо: прятать дверь вместо того, чтобы её запирать

Самый популярный совет в статьях про безопасность — переименовать страницу входа. Не делайте этого: вход должен остаться по штатному адресу /wp-login.php. Скрытие не защищает, новый адрес находят по редиректам, по разнице в ответах сервера и по ссылкам в теме.

Зато это регулярно ломает вход: плагин обновился или отключился при сбое — старый адрес закрыт, новый не работает, а кэширующие плагины иногда отдают страницу входа как обычную. И чаще всего адрес просто забывают: я в этом деле с 2005 года и фразу «мы не можем зайти на свой сайт, там был какой-то другой адрес» слышал чаще, чем «нас взломали через форму входа».

То же с парольной защитой каталога админки на уровне сервера: внутри лежит обработчик асинхронных запросов, нужный формам на публичной части, и загрузка файлов начинает отваливаться.

Замена скрытности одна: ограничить число попыток и добавить второй фактор — остальные слои я собирал отдельно, как защитить сайт от взлома. Проверка «я не робот» на форме входа уместна: страница одна и скорость там не важна. А на формах заявок она тянет сторонние скрипты и обходится дороже, чем приносит.

Когда журнал не нужен и когда он бесполезен

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

Дальше про вред. Если плагин пишет всё в базу без ограничения срока, таблица разрастается до сотен тысяч строк и админка начинает тормозить на списках. Ротацию надо настроить сразу: тридцати-девяноста дней хватает для любого разбора.

Второе: журнал не защищает и не блокирует, он показывает. Летопись того, как вас ломают, взлому не мешает, а ставят её как раз вместо лимита попыток — это подмена.

Третье и главное: на заражённом сайте журналу плагина верить нельзя. Взломщик с правами администратора удаляет записи или работает от имени существующего пользователя, так что пустой журнал — не доказательство чистоты. Доверять надо журналам сервера.

И четвёртое: журнал бесполезен, если инцидент старше срока хранения, а заражение часто находят через недели. Значит, нужен внешний контроль — хотя бы мониторинг доступности сайта.

Чужой вход уже был: порядок действий за первый час

Порядок важнее скорости. Главная ошибка — начать с чистки файлов, оставив вход открытым: пока вы правите код, его переписывают обратно. Логика та же, что при любом угоне учётной записи: что делать в первый час после взлома мессенджера.

Шаг	Что сделать	Зачем именно так
1	Если на страницах чужой код или редиректы — закрыть сайт заглушкой	не собирать санкции поисковика и не заражать посетителей
2	Сменить пароли: администраторы, база, FTP, панель хостинга, почта восстановления	вход мог быть не через админку
3	Заменить секретные ключи и соли в wp-config.php	без этого чужая сессия живёт и после смены пароля
4	Проверить пользователей: удалить незнакомых, сверить роли и почту	подменённая почта позволяет восстановить пароль
5	Проверить запланированные задачи WordPress	там прячут повторный запуск кода
6	Найти файлы, изменённые за последние дни	видно, куда вписали код
7	Проверить .htaccess в корне и в каталоге загрузок, а также wp-config.php	типовые места для редиректов и вставок
8	Переустановить ядро и активные плагины из официальных источников, неиспользуемые удалить целиком	заменить код надёжнее, чем искать вставки глазами; файлы отключённого плагина доступны по прямому адресу
9	Открыть раздел «Безопасность и нарушения» в Яндекс.Вебмастере	видно, нашёл ли код поисковик; оттуда же перепроверка
10	Проверить, не появились ли чужие страницы и исходящие ссылки	частая цель взлома — ссылки с сайта
11	Если чистка не даётся — чистый бэкап, но после шагов 2 и 3	бэкап возвращает файлы и не закрывает вход
12	Включить сайт, поставить второй фактор и внешний мониторинг	о повторной попытке узнать сразу

Про бэкап отдельно: восстановление без смены паролей возвращает взлом вместе с сайтом. Файлы стали чистыми, способ попасть внутрь остался тем же, и через сутки всё повторится — только теперь вы решите, что «чистка не помогла». Вторая ловушка: копия может быть уже заражённой, ведь заражение находят через недели, а копии хранятся семь дней — берите заведомо более старую.

Отдельная развилка — почта. Если доступ получили к ящику, на который настроено восстановление, смена пароля в WordPress ничего не даёт: его восстановят заново. Ящик проверяется первым, вместе с правилами пересылки, — полный порядок в материале взломали рабочую почту.

Остаётся SEO-часть: запросить перепроверку и посмотреть, не выпали ли страницы из индекса. Какие отчёты открывать — в материале про три отчёта Яндекс.Вебмастера. Если непонятно, что в коде лишнее, это работа в рамках доработки сайта.

Девять ошибок, из-за которых журнал не спасает

• Смотреть только журнал плагина. Его могли подчистить изнутри.
• Ставить два плагина безопасности сразу. Конфликты правил и ложные блокировки.
• Прятать страницу входа. Не защищает, ломает вход после обновлений.
• Сменить пароли и не сменить соли. Чужая сессия живёт дальше, иногда неделями.
• Восстановить бэкап и успокоиться. Вход остался открыт, а копия может быть заражённой.
• Оставить подрядчику права администратора. Пароль годами живёт в чьей-то переписке.
• Один пароль на админку, почту и хостинг. Утечка в одном месте открывает всё.
• Выключить журнал после чистки. Через месяц та же история, и смотреть нечего.
• Считать ботов посетителями. Перебор раздувает статистику визитов.

Профилактика, которую делают один раз

• Обновления. Автообновление ядра включить, плагины проверять раз в месяц: частый путь внутрь — уязвимость в плагине, который год не обновляли.
• Ревизия плагинов и тем. В каталоге указана дата последнего обновления: «не обновлялся два года» — повод убрать совсем.
• Бэкапы с проверкой. Копия, которую ни разу не разворачивали, не существует.
• Отдельная запись подрядчику вместо общего пароля администратора, и удалить её после работ.
• Менеджер паролей. Длинные разные пароли везде, ничего не надо помнить и хранить в переписке.
• Почта восстановления. Доступ к ящику у вас, второй фактор включён, чужой пересылки нет.
• Мониторинг. О проблеме лучше узнавать от сервиса, а не от клиента с незаполненной заявкой.

Если непонятно, с чего начинать, начните с инвентаризации: какие плагины стоят, когда обновлялись, у кого есть доступ. Это же первое, что я смотрю, когда делаю бесплатный аудит сайта.

Коротко

• Ядро WordPress журнал входов не ведёт: в базе есть только дата регистрации и маркеры действующих сессий.
• Источников четыре: журналы сервера, плагин журналирования, письма плагина безопасности и метаданные пользователей.
• Журналы сервера полнее всех, но логинов не знают и живут от нескольких дней до пары недель: скачивать сразу.
• Код 200 на отправку формы входа — пароль не подошёл, код 302 — вход выполнен. Незнакомый адрес с 302 — инцидент.
• Войдите один раз сами и найдите свою строку: это эталон для вашего сервера.
• Обращения к xmlrpc.php, запросы к списку пользователей и адреса с номером автора — разведка логинов.
• Журнал ведут Simple History, WP Activity Log, Wordfence Security, All In One WP Security & Firewall, Sucuri Security и Limit Login Attempts Reloaded; второй фактор — Two Factor и WP 2FA. Плагин безопасности нужен один.
• Безболезненно: развести логин и имя автора, убрать логин admin, запретить редактор файлов, выключить показ ошибок.
• С ценой: запрет установки плагинов требует ручных обновлений, лимит попыток может запереть вас самих.
• Страницу входа прятать не надо: адрес находят, а вход ломается после обновлений. Работают лимит попыток и второй фактор.
• После чужого входа: заглушка, пароли, соли, пользователи, задачи, изменённые файлы, переустановка ядра, Вебмастер. Бэкап без смены паролей возвращает взлом.