Ko se prijavio na mašinu: logovi prijave
Gde videti uspešne i neuspešne prijave, kako čitati last, lastb i journalctl, kako pratiti radnje preko sudo i kako podesiti čuvanje logova.
Ažurirano 23. avgust 2026.
Svaki login na mašinu ostavlja trag. To što umeš da pročitaš te tragove za pet minuta razlikuje mirnu analizu incidenta od nagađanja.
Kratak pregled
last -a -n 20
lastb -a -n 20
lastlog
who
w
last prikazuje uspešne prijave sa adresama, lastb — neuspele pokušaje, lastlog — kada se svaki korisnik poslednji put prijavio. who i w prikazuju ko je trenutno na mašini.
Ako lastlog prikazuje datum prijave za sistemskog korisnika kao što je www-data, to je ozbiljan razlog za istragu.
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
Ključni redovi:
| Red | Značenje |
|---|---|
Accepted publickey for artem | Uspešna prijava ključem |
Accepted password for root | Uspešna prijava lozinkom — razlog za zabrinutost |
Failed password for invalid user admin | Bruteforsovanje nepostojećih imena, šum u pozadini |
Disconnected from authenticating user | Pokušaj prekinut |
Na Debianu i Ubuntuu isti događaji se dupliraju u /var/log/auth.log; na AlmaLinuxu u /var/log/secure.
grep "Accepted" /var/log/auth.log
grep -c "Failed password" /var/log/auth.log
Stotine neuspešnih pokušaja dnevno na javnoj adresi su normalne. Nenormalno je nešto drugo: uspešna prijava sa adrese koju ne prepoznaješ. fail2ban pomaže protiv šuma.
Šta je urađeno nakon prijave
journalctl -t sudo -n 100
grep sudo /var/log/auth.log
cat /home/artem/.bash_history
Istorija komandi je nepouzdana: lako se briše i ne beleži se tokom neinteraktivnih sesija. sudo log je mnogo iskreniji — održava ga sistem, a ne shell. Još jedan argument u prilog šemi „redovan korisnik plus sudo“ opisanoj u članku korisnici i sudo.
Potpuni audit na nivou kernela:
apt install -y auditd
auditctl -w /etc/passwd -p wa -k passwd_changes
ausearch -k passwd_changes
Skladištenje
Podrazumevano, systemd journal može da živi u memoriji i da se izgubi pri restartu. To je loše za analizu incidenta. Fajl /etc/systemd/journald.conf:
[Journal]
Storage=persistent
SystemMaxUse=500M
MaxRetentionSec=1month
systemctl restart systemd-journald
journalctl --disk-usage
Ograničenje veličine je obavezno: journal koji je pojeo disk zaustavlja servise.
Česte greške
| Greška | Posledica | Rešenje |
|---|---|---|
| Journal se ne čuva između restarta | Tragovi se gube | Storage=persistent |
Oslanjanje samo na .bash_history | Podaci se lako falsifikuju | Proveri sudo i auditd logove |
| Nije ograničena veličina journala | Disk se napunio | SystemMaxUse |
| Brutefors šum se tretira kao hak | Lažna uzbuna | Gledaj Accepted, ne Failed |
Ako nađeš uspešnu prijavu sa tuđe adrese, logovi na samoj mašini više ne mogu da se smatraju pouzdanim: onaj ko se prijavio mogao je da ih izmeni. Prati članak znaci kompromitacije i računaj na to da će mašina morati da se reinstalira.