В логах успешный вход не с вашего IP: план на первые 15 минут

MAATRIX

Вы открываете last или проверяете панель мониторинга — и видите строку: успешный вход, ваш логин или ключ, но IP не ваш и не из офиса. Первая реакция — оборвать сессию и менять всё разом. Это ошибка: поспешные действия спугивают атакующего, если он ещё внутри, и стирают улики, по которым можно понять, что он успел сделать. Ниже — план на первые 15 минут: что зафиксировать, что проверить и в каком порядке действовать, чтобы не потерять картину происшествия и не наделать вреда самому.

Минута 0-2: не паникуйте и ничего резко не выключайте

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

Откройте новый терминал — не в той сессии, где увидели подозрительный вход, а отдельное подключение. Если есть доступ к панели провайдера с web-консолью (out-of-band, не через SSH сервера), держите её под рукой: если атакующий решит перекрыть вам SSH, консоль через панель останется рабочим каналом.

Сразу зафиксируйте текущее время и то, что вы увидели, в отдельном файле на своей машине — не на сервере:

date -u
echo "Обнаружен вход: <IP>, <время>, <пользователь>" >> ~/incident-notes.txt

Это не для протокола ради протокола — через 20 минут разбора детали смешаются, и вы забудете, что видели изначально, а что уже во время расследования.

Минуты 2-5: зафиксируйте факт входа — время, IP, метод

Прежде чем что-то трогать, соберите точные данные о самом входе. На Ubuntu/Debian и большинстве систем с systemd:

# история входов с полными датами и IP
last -Fiw

# только этот пользователь
last -Fiw имя_пользователя

# неуспешные попытки перед успешным входом — брутфорс или подбор?
lastb -Fiw | head -50

# кто в системе прямо сейчас
who -a
w

Если last пуст или подозрительно короткий — это тоже сигнал: утилита читает /var/log/wtmp, и если файл почищен, это отдельная находка, которую стоит записать отдельно.

Дальше — сырые логи аутентификации, они дают больше контекста, чем last:

# Debian/Ubuntu
grep -E "Accepted (password|publickey)" /var/log/auth.log | tail -100

# RHEL/AlmaLinux/CentOS и системы с journald
journalctl -u sshd --since "2026-08-25" --until "2026-08-30" | grep -i accepted

# если ключ — какой именно ключ приняли
journalctl -u sshd | grep -i "accepted publickey" | grep <IP>

Обратите внимание на разницу между Accepted password и Accepted publickey. Если вход был по паролю там, где вы давно перешли на ключи — это отдельный тревожный флаг: либо пароль всё ещё разрешён в sshd_config (PasswordAuthentication yes), либо кто-то его знает. Если вход был по ключу — выясните, какой именно ключ приняли: сравните fingerprint из лога с тем, что лежит у вас и у сотрудников, которым положен доступ.

# fingerprint конкретного ключа для сравнения
ssh-keygen -lf ~/.ssh/id_ed25519.pub

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

Минуты 5-9: что делал этот сеанс — команды, процессы, файлы

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

История команд. Если это Bash с включённым HISTTIMEFORMAT, у вас будут временные метки:

HISTTIMEFORMAT="%F %T " history
cat ~/.bash_history
cat /home/*/.bash_history
cat /root/.bash_history

Учтите: опытный атакующий чистит или отключает историю (unset HISTFILE, export HISTSIZE=0, симлинк .bash_history на /dev/null). Пустая история сразу после подозрительного входа — сама по себе улика, а не повод расслабиться.

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

ps auxf
ps -eo pid,ppid,user,lstart,cmd --sort=-start_time | head -30

# сетевые соединения и слушающие порты
ss -tulpn
lsof -i -P -n

Особое внимание — процессам, у которых бинарник запущен из /tmp, /dev/shm, /var/tmp или скрытых каталогов вида /usr/bin/.cache. Это классическое место для дропперов, потому что часто монтируется с noexec не везде и легко не бросается в глаза.

Изменённые и созданные файлы. Если знаете примерное время входа, ищите всё, что менялось после этой метки:

# создайте маркер с точным временем начала подозрительной сессии
touch -d "2026-08-29 14:32:00" /tmp/marker

find / -xdev -newer /tmp/marker -type f 2>/dev/null | grep -v -E "^/(proc|sys|tmp)"

# изменения за последние сутки конкретно
find /etc /home /root /var/www -mtime -1 -type f

Если на сервере стоит auditd — это огромное преимущество, потому что даёт точную последовательность syscall'ов, а не догадки по таймстампам. Если его пока нет, поставить его стоит уже после того, как разберётесь с этим инцидентом, чтобы в следующий раз не гадать.

Сохраните всё, что нашли, копированием логов на свою машину или на другой сервер — не оставляйте единственную копию улик там, где до неё может дотянуться тот же атакующий:

rsync -avz root@сервер:/var/log/auth.log* ~/incident-2026-08-29/
rsync -avz root@сервер:/var/log/wtmp ~/incident-2026-08-29/

Минуты 9-11: точки закрепления — где ищут постоянный доступ

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

Основные места для проверки:

Отдельно проверьте .bashrc, .profile и /etc/profile.d/ — туда иногда дописывают код, который выполняется при каждом новом входе легитимного пользователя, что даёт атакующему повторный доступ, даже если основной ключ вы уже отозвали.

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

Минуты 11-13: не обрывайте сессию поспешно, если она ещё активна

Если who или w показывают, что подозрительная сессия всё ещё открыта — не спешите её убивать командой kill по PID или разрывом соединения на файрволе. Это контринтуитивно, но резкий обрыв активной сессии часто действует как сигнал тревоги: атакующий, увидев, что его выкинуло, может среагировать быстрее, чем вы успеете закрыть остальные дыры — стереть логи, развернуть дополнительный бэкдор про запас или ускорить то, что и так уже делал.

Пока сессия активна и вы уже сняли достаточно данных (кто, когда, какие процессы, какие файлы), у вас есть выбор из двух стратегий:

• Тихое наблюдение. Если инцидент не выглядит как активная разрушительная атака (майнинг, шифровальщик, вывод данных прямо сейчас) — можно понаблюдать ещё несколько минут через ps, ss, tcpdump на отдельном интерфейсе, чтобы понять масштаб, прежде чем действовать. Это оправдано, только если вы уверены, что параллельно не идёт вывод чувствительных данных.
• Контролируемая изоляция. Если видно, что сессия что-то активно делает во вред (аномальный исходящий трафик, попытки записи в критичные каталоги) — режьте не саму SSH-сессию точечно, а исходящий трафик на уровне файрвола для конкретного IP, оставляя видимость происходящего на сервере:

# заблокировать конкретный подозрительный IP, не трогая саму сессию явно
iptables -A INPUT -s <IP_атакующего> -j DROP
iptables -A OUTPUT -d <IP_атакующего> -j DROP

Если у вас нет уверенности, какую стратегию выбрать — по умолчанию безопаснее вторая: заблокировать дальнейшую сетевую активность конкретного IP, но не убивать процессы и не перезагружать сервер, пока не сняли снимок состояния. Более подробный разбор про изоляцию именно активного взлома — в статье «Взломали сервер: пошаговый план», она логично продолжает этот план после первых 15 минут, если подтвердится полноценная компрометация.

Минуты 13-15: смена паролей, ключей и что делать дальше

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

Порядок действий:

1. Смените пароль и все SSH-ключи затронутого пользователя и root, добавив новые ключи и удалив старые из authorized_keys — не просто «добавить новый», а именно вычистить список от всего, что не опознали как своё.
2. Отзовите и перевыпустите ключи ко всем сервисам, к которым у скомпрометированного аккаунта был доступ: API-токены, ключи деплоя, доступ к базе, интеграции CI/CD.
3. Проверьте вторичные учётки — если этот пользователь мог читать .ssh других аккаунтов или файлы с паролями (.env, конфиги приложений), считайте скомпрометированными и их тоже.
4. Включите 2FA для SSH, если её ещё нет — это радикально снижает шанс повтора именно такого сценария (вход по угнанному паролю или ключу). Пошагово это описано в статье про двухфакторную аутентификацию SSH.
5. Заведите ротацию ключей и секретов на регулярной основе, а не только по факту инцидента — практика описана в статье про ротацию секретов и ключей.

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

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

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