누가 머신에 로그인했나요: 로그인 로그
성공 및 실패한 로그인을 어디서 확인하는지, last, lastb, journalctl을 읽는 방법, sudo를 통한 작업 추적, 로그 보존 설정 방법이에요.
업데이트 2026년 8월 23일
모든 로그인은 흔적을 남겨요. 그 흔적을 5분 안에 읽어낼 수 있느냐가 침착한 사고 분석과 추측을 갈라놓아요.
빠른 개요
last -a -n 20
lastb -a -n 20
lastlog
who
w
last는 주소와 함께 성공한 로그인을, lastb는 실패한 시도를, lastlog는 각 사용자가 마지막으로 로그인한 시점을 보여줘요. who와 w는 지금 누가 머신에 접속해 있는지 보여줘요.
lastlog에 www-data 같은 시스템 사용자의 로그인 날짜가 찍혀 있다면, 그건 조사를 해봐야 할 심각한 이유예요.
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
주요 라인:
| 라인 | 의미 |
|---|---|
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 journal은 메모리에 있다가 재부팅 시 사라질 수 있어요. 사고 분석에는 좋지 않죠. /etc/systemd/journald.conf 파일:
[Journal]
Storage=persistent
SystemMaxUse=500M
MaxRetentionSec=1month
systemctl restart systemd-journald
journalctl --disk-usage
크기 제한은 필수예요. 디스크를 다 먹어버린 journal은 서비스를 멈추게 해요.
흔한 실수
| 실수 | 결과 | 해결 |
|---|---|---|
| 재부팅 사이에 journal이 저장되지 않음 | 흔적이 사라짐 | Storage=persistent |
.bash_history에만 의존 | 데이터를 위조하기 쉬움 | sudo와 auditd 로그를 확인 |
| journal 크기를 제한하지 않음 | 디스크가 가득 참 | SystemMaxUse |
| 무차별 대입 잡음을 해킹으로 간주 | 잘못된 경보 | Failed가 아니라 Accepted를 확인 |
다른 사람의 주소에서 성공한 로그인을 발견했다면, 머신 자체의 로그는 더 이상 신뢰할 수 없어요. 로그인한 사람이 로그를 편집했을 수 있기 때문이죠. 침해 징후 문서를 따라 조치하고, 머신을 재설치해야 한다고 가정하세요.