Kto sa prihlásil do stroja: prihlasovacie logy

Každé prihlásenie do stroja za sebou zanecháva stopu. Vedieť si tie stopy prečítať za päť minút je rozdiel medzi pokojným vyšetrovaním incidentu a hádaním.

Rýchly prehľad

last -a -n 20
lastb -a -n 20
lastlog
who
w

last zobrazuje úspešné prihlásenia s adresami, lastb — neúspešné pokusy, lastlog — kedy sa každý používateľ naposledy prihlásil. who a w zobrazujú, kto je na stroji práve teraz.

Ak lastlog zobrazuje dátum prihlásenia pre systémového používateľa, ako napríklad www-data, je to vážny dôvod na vyšetrovanie.

systemd journal

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

Kľúčové riadky:

Na Debiane a Ubuntu sa tie isté udalosti duplikujú v /var/log/auth.log; na AlmaLinuxe v /var/log/secure.

grep "Accepted" /var/log/auth.log
grep -c "Failed password" /var/log/auth.log

Stovky neúspešných pokusov za deň na verejnej adrese sú normálne. Abnormálne je niečo iné: úspešné prihlásenie z adresy, ktorú nepoznáš. Proti šumu pomáha fail2ban.

Čo sa dialo po prihlásení

journalctl -t sudo -n 100
grep sudo /var/log/auth.log
cat /home/artem/.bash_history

História príkazov je nespoľahlivá: ľahko sa vymaže a počas neinteraktívnych relácií sa nezaznamenáva. Oveľa čestnejší je log sudo — vedie ho systém, nie shell. Ďalší argument v prospech schémy „bežný používateľ plus sudo“ opísanej v článku používatelia a sudo.

Úplný audit na úrovni jadra:

apt install -y auditd
auditctl -w /etc/passwd -p wa -k passwd_changes
ausearch -k passwd_changes

Ukladanie

Štandardne môže systemd journal žiť v pamäti a pri reštarte sa stratiť. To je pre vyšetrovanie incidentov zlé. Súbor /etc/systemd/journald.conf:

[Journal]
Storage=persistent
SystemMaxUse=500M
MaxRetentionSec=1month

systemctl restart systemd-journald
journalctl --disk-usage

Obmedzenie veľkosti je povinné: journal, ktorý zožral disk, zastaví služby.

Časté chyby

Ak nájdeš úspešné prihlásenie z cudzej adresy, logy na samotnom stroji už nemožno považovať za spoľahlivé: ten, kto sa prihlásil, ich mohol upraviť. Postupuj podľa článku príznaky kompromitácie a počítaj s tým, že stroj bude potrebné preinštalovať.