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

MAATRIX

Письмо от хостинга или пуш от CMS: «Обнаружен вход в панель управления с нового местоположения — Вьетнам». Логин ваш, пароль подошёл с первого раза — вроде бы всё штатно, но вы точно не были во Вьетнаме. Первая реакция — либо запаниковать и всё удалить, либо махнуть рукой («наверное, VPN»). Оба варианта неправильные. Ниже — порядок действий на ближайшие 15–30 минут: как проверить сессию, не потеряв улики, и закрыть доступ, даже если окажется, что это были вы сами через прокси в командировке.

Сначала: не паника и не игнор

Уведомление о входе из незнакомой страны срабатывает на реальную геолокацию IP-адреса, а не на факт компрометации — это разные вещи. Легитимные причины для такого алерта встречаются регулярно:

• вы сами включили VPN или сменили exit-node прокси;
• вы (или коллега с доступом) в командировке, а панель ранее не видела входов не из домашнего региона;
• мобильный оператор завернул трафик через роуминговый шлюз в другой стране — типично для 4G/5G на границе или в поездках, IP при этом «чужой», хотя человек в соседнем городе;
• корпоративный VPN компании имеет exit-узел за рубежом, и весь трафик офиса выглядит как вход «из Германии», хотя сотрудник сидит в Москве;
• база GeoIP у панели устарела и путает страну провайдера с страной физического подключения — расхождения в 5–10% для мобильных и облачных IP-диапазонов не редкость.

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

Шаг 1. Зафиксируйте детали сессии, пока их не перезаписали

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

Что фиксировать:

• IP-адрес входа целиком, не только страна из письма;
• точное время входа (и выхода, если панель его пишет) с таймзоной;
• User-Agent — тип устройства, браузер, ОС;
• было ли это единственное подключение или несколько подряд с разных IP.

Проверить принадлежность IP:

whois 185.220.101.42 | grep -iE "country|netname|org"
curl -s https://ipinfo.io/185.220.101.42/json

Второй запрос отдаёт JSON с полем country, org (провайдер) и, часто, hostname — по нему сразу видно, дата-центр это, мобильная сеть или домашний провайдер. Если org похож на облачного хостера (DigitalOcean, Hetzner, OVH, AWS) — это с высокой вероятностью не личное устройство пользователя, а VPN-сервер, прокси или, в худшем случае, инфраструктура атакующего.

Где искать сами данные о входе в зависимости от панели:

Если у панели своего журнала нет (частый случай для самописных админок и WordPress без плагинов), придётся смотреть логи веб-сервера напрямую:

grep "wp-login.php" /var/log/nginx/access.log | grep "POST" | tail -50

Это покажет все POST-запросы на форму логина — по времени и IP можно сопоставить с тем, что пришло в уведомлении. Если подозрительных входов оказалось несколько или найдена активность за пределами одной сессии, дальнейший разбор — уже не эта статья, а полноценный incident response plan при взломе: там расписан порядок сбора улик без их случайного уничтожения.

Шаг 2. Проверьте, что успели сделать за эту сессию

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

Для CMS (WordPress и подобные):

# новые или изменённые файлы за последние 48 часов
find /var/www/site -type f -mtime -2 -ls

# список администраторов — не появился ли лишний
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Отдельно проверьте: не появился ли новый пользователь с правами администратора, не менялся ли редактор тем/плагинов (Appearance → Theme Editor — классический вектор для внедрения бэкдора одной строкой в functions.php), не изменилось ли содержимое wp-config.php и .htaccess.

Для панелей хостинга — проверьте разделы, где обычно оставляют закладки:

• список пользователей / поддоменов панели — не создан ли новый аккаунт с доступом;
• список SSH-ключей и cron-задач на связанных серверах;
• DNS-записи домена — не добавлена ли запись, уводящая почту или сайт на чужой сервер;
• API-токены и ключи интеграций (платёжные шлюзы, почтовые сервисы, репозитории) — если они видны в интерфейсе, их нужно считать скомпрометированными и перевыпустить в любом случае.

Если в панели есть журнал действий (audit log) — это быстрее всего: он покажет конкретные операции с точным временем, привязанным к сессии из шага 1. Если журнала нет, ориентируйтесь на время изменения файлов и записей в базе — это менее точно, но лучше, чем ничего. Как отличить последствия реального вторжения от совпадения с плановым обновлением или багом хостинга, подробно разобрано в статье «Скомпрометирован или просто глючит» — пригодится, если признаки неоднозначные.

Шаг 3. Смените пароль и завершите все активные сессии

Это нужно сделать в любом случае — даже если по итогам шагов 1–2 вы на 90% уверены, что вход был легитимным. Оставшиеся 10% — это ситуация, когда пароль утёк отдельно (фишинг, утечка базы другого сервиса с тем же паролем), а совпадение с вашей поездкой чисто по времени случайное.

Порядок:

1. Смените пароль на новый, уникальный именно для этой панели — не вариацию старого.
2. Завершите все активные сессии, а не только подозрительную — иначе атакующий, если он реален, продолжит работать с уже открытой сессией даже после смены пароля.
3. Перевыпустите все API-токены и ключи, до которых был доступен интерфейс панели за время сессии.

Смена пароля сама по себе не всегда обнуляет уже выданные токены сессий — это зависит от механизма аутентификации:

• cPanel/Plesk/ISPmanager: смена пароля обычно инвалидирует активные веб-сессии автоматически; отдельно проверьте раздел SSH-доступа — там ключи и пароли меняются независимо.
• WordPress: смена пароля пользователя WordPress не сбрасывает уже выданные cookie аутентификации сама по себе в старых версиях без дополнительных мер. Гарантированно оборвать все сессии — пересоздать соль в wp-config.php:

wp config shuffle-salts

Команда меняет AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY и остальные соли — все ранее выданные cookie сразу становятся невалидными, залогиненным останется только тот, кто войдёт заново с новым паролем. Без WP-CLI то же самое можно сделать вручную, вставив свежий набор ключей с https://api.wordpress.org/secret-key/1.1/salt/ в wp-config.php.

• Самописные приложения с сессиями в базе: если сессии хранятся в таблице (sessions, user_sessions), проще всего выполнить DELETE FROM sessions WHERE user_id = ... или, если предусмотрено поле версии токена, увеличить его — это разлогинит все устройства сразу, включая мобильные, о которых вы могли забыть.

Если пароль от этой панели использовался повторно где-то ещё (даже частично, с небольшими вариациями) — смените его и там. Предполагать, что «раз панель одна пострадала, остальное не при чём» в этой ситуации не стоит.

Шаг 4. Включите MFA, если её ещё не было

Если по итогам разбора причина оказалась безобидной (VPN, командировка, роуминг оператора) — это всё равно повод закрыть дыру, а не выдохнуть и забыть. Пароль сам по себе — единственный фактор, и рано или поздно похожая ситуация повторится, только в следующий раз без счастливого совпадения.

Практическая проблема в том, что далеко не во всех панелях MFA включён по умолчанию, а в части старых версий его вообще нет как штатной функции — тогда нужен обходной путь через reverse-proxy с отдельной аутентификацией или плагин. Разбор того, как включить двухфакторную аутентификацию конкретно в популярных панелях управления — ispmanager, cPanel, phpMyAdmin, панелях мониторинга — есть в отдельной статье: «Двухфакторная аутентификация для панелей управления». Общий принцип для любого варианта:

• используйте TOTP-приложение (Google Authenticator, Aegis, любой совместимый) — не SMS, которую можно перехватить через подмену SIM или социнженерию оператора;
• сохраните резервные коды восстановления не в том же аккаунте, что и панель (не в почте, привязанной к тому же логину-паролю) — иначе при компрометации почты MFA не защитит;
• включайте MFA для всех учётных записей с доступом к панели, а не только для той, что засветилась в инциденте — если доступ был у нескольких человек, у всех должен быть второй фактор.

Если такой вход случился с общей или сервисной учётной записью (например, «admin», которым пользуются несколько человек) — это отдельный повод перейти на именные аккаунты: тогда через полгода не придётся гадать, кто именно заходил и был ли это вообще человек из команды.

Шаг 5. Свяжитесь с владельцем учётки — по другому каналу

Если панелью пользуется не только вы (агентство ведёт сайт клиента, у команды общий доступ, аккаунт делегирован сотруднику) — прежде чем делать выводы, спросите напрямую, был ли это он. Это самый быстрый способ закрыть вопрос «легитимно или нет» без гадания по IP.

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

Два исхода:

• Да, это был я — отлично, инцидент закрыт, но пароль всё равно стоит сменить и MFA включить (шаги 3–4 всё ещё нужны, а не отменяются).
• Нет, это не я — считайте компрометацию подтверждённой и переходите к полноценному разбору. Дальнейшие шаги — поиск точки входа (откуда мог утечь пароль: фишинг, повторное использование пароля, стилер на рабочей машине), смена доступов везде, где использовался тот же пароль, и, если на сервере уже что-то поменяли, — пошаговый план действий при взломе.

Если владелец учётки недоступен (уволен, в отпуске без связи, единственный админ на больничном) — не ждите ответа неопределённо долго. Через разумное время (для рабочей учётки — обычно в пределах пары часов) действуйте по худшему сценарию: меняйте пароль и MFA, оставив себе доступ для расследования, а объяснение получите постфактум.

Частые вопросы