Хто входив на машину: журнали входів
Де переглянути успішні та невдалі входи, як читати last, lastb і journalctl, як відстежувати дії через sudo та налаштувати зберігання журналів.
Оновлено 23 серпня 2026 р.
Кожен вхід на машину залишає слід. Уміння прочитати ці сліди за п'ять хвилин — це те, що відрізняє спокійний розбір інциденту від здогадок.
Швидкий огляд
last -a -n 20
lastb -a -n 20
lastlog
who
w
last показує успішні входи з адресами, lastb — невдалі спроби, lastlog — коли кожен користувач востаннє входив. who і w показують, хто зараз на машині.
Якщо lastlog показує дату входу для системного користувача на кшталт www-data, це серйозна причина для розслідування.
Журнал systemd
journalctl -u ssh -n 100
journalctl -u ssh --since "2026-08-20" --until "2026-08-21"
journalctl _COMM=sshd | grep "Accepted"
journalctl _COMM=sshd | grep "Failed password" | tail -50
Ключові рядки:
| Рядок | Значення |
|---|---|
Accepted publickey for artem | Успішний вхід за ключем |
Accepted password for root | Успішний вхід за паролем — привід для занепокоєння |
Failed password for invalid user admin | Перебір неіснуючих імен, фоновий шум |
Disconnected from authenticating user | Спроба перервана |
У Debian і Ubuntu ті самі події дублюються в /var/log/auth.log; в AlmaLinux — у /var/log/secure.
grep "Accepted" /var/log/auth.log
grep -c "Failed password" /var/log/auth.log
Сотні невдалих спроб на добу за публічною адресою — це нормально. Аномальне інше: успішний вхід з адреси, якої ви не впізнаєте. Проти шуму допомагає fail2ban.
Що робили після входу
journalctl -t sudo -n 100
grep sudo /var/log/auth.log
cat /home/artem/.bash_history
Історія команд ненадійна: її легко очистити, і вона не записується під час неінтерактивних сесій. Журнал sudo значно чесніший — його веде система, а не оболонка. Ще один аргумент на користь схеми «звичайний користувач плюс sudo», описаної в статті користувачі та sudo.
Повний аудит на рівні ядра:
apt install -y auditd
auditctl -w /etc/passwd -p wa -k passwd_changes
ausearch -k passwd_changes
Зберігання
За замовчуванням журнал systemd може жити в пам'яті й губитися під час перезавантаження. Для розбору інцидентів це погано. Файл /etc/systemd/journald.conf:
[Journal]
Storage=persistent
SystemMaxUse=500M
MaxRetentionSec=1month
systemctl restart systemd-journald
journalctl --disk-usage
Обмеження розміру обов'язкове: журнал, який з'їв диск, зупиняє сервіси.
Типові помилки
| Помилка | Наслідок | Рішення |
|---|---|---|
| Журнал не зберігається між перезавантаженнями | Сліди втрачено | Storage=persistent |
Покладатися лише на .bash_history | Дані легко підробити | Перевіряйте журнали sudo та auditd |
| Не обмежили розмір журналу | Диск заповнився | SystemMaxUse |
| Сприймати шум перебору як злам | Хибна тривога | Дивіться на Accepted, а не на Failed |
Якщо ви виявили успішний вхід з чужої адреси, логи на самій машині вже не можна вважати надійними: той, хто увійшов, міг їх відредагувати. Дотримуйтеся статті ознаки компрометації і виходьте з того, що машину доведеться перевстановити.