정보보안기사 - 1.10 리눅스 로그 분석 (wtmp, syslog)Linux Log Analysis wtmp and syslog - InfoSec Engineer 1.10
📅
들어가기 전에 🔗
지난 1.9편에서는 해커가 시스템의 출입문인 패스워드를 어떻게 뚫고 들어오는지 알아보았습니다.
시스템에 누군가 침입하려고 시도했거나 실제로 침입했다면, 그 과정은 반드시 발자국을 남깁니다.
우리는 이 발자국을
로그
(Log)라고 부릅니다.리눅스 시스템은 사용자들의 모든 접속 기록과 시스템 내부에서 일어나는 상태 변화를 꼼꼼하게 기록합니다.
보안 담당자는 이 기록들을 분석하여 언제, 누가, 어디서 접근했는지 추적할 수 있어야 합니다.
오늘은 리눅스 접속 로그의 종류와 시스템 로그 설정 방법에 대해 상세히 알아보겠습니다.
리눅스 접속 로그 파일 4총사 🔗
리눅스는 사용자의 로그인과 로그아웃 내역을 주로
/var/log
디렉토리 하위에 저장합니다.
이 파일들은 일반적인 텍스트 파일이 아니라 기계어 형태인 바이너리
(Binary)로 저장되는 특징이 있습니다.
따라서 편집기로 직접 열어볼 수 없으며, 전용 명령어를 사용해야만 내용을 확인할 수 있습니다.- utmp현재 시스템에 로그인하여 접속 중인 사용자들의 상태 정보를 담고 있습니다. 터미널에서w명령어 또는who명령어를 입력하여 확인할 수 있습니다.
- wtmp사용자들의 성공한 로그인, 로그아웃 기록과 시스템의 부팅 및 종료 기록을 누적하여 저장합니다.last명령어로 내용을 확인합니다.
- btmp로그인에 실패한 기록(Bad Login)만 따로 모아서 저장합니다. 해커의 무차별 대입 공격을 파악할 때 유용하며,lastb명령어로 확인합니다.
- lastlog모든 시스템 계정의 가장 마지막 로그인 시간과 접속 IP를 기록합니다.lastlog명령어로 확인하며, 오랫동안 쓰지 않은 휴면 계정을 찾을 때 씁니다.
사용자 로그인 로그 시스템
비정상 로그인 시도 추적 실습 🔗
가장 활용도가 높은
last
명령어와 lastb
명령어를 직접 터미널에 입력하여 결과를 해석해 보겠습니다.1. 성공한 로그인 기록 확인 (wtmp) 🔗
last
명령어는 /var/log/wtmp
파일을 읽어서 가장 최근의 접속 기록부터 역순으로 보여줍니다. # 최근 5개의 로그인 및 부팅 기록만 출력합니다.
last -n 5 # 출력 결과 예시
# 계정명 접속장치 접속IP(또는 상태) 접속시간 머문시간
root pts/0 192.168.0.10 Sat Mar 14 10:00 still logged in
user1 pts/1 10.0.0.5 Sat Mar 14 09:30 - 09:45 (00:15)
reboot system boot 0.0.0.0 Fri Mar 13 18:00 (16:20)
위 결과를 통해
root
계정은 현재 접속 중이며, user1
계정은 15분 동안 머물다 나갔음을 알 수 있습니다.
또한 시스템이 언제 재부팅되었는지도 확인할 수 있습니다.필자 기록 분석 🔗
wtmp 결과 확인
| 사용자 (USER) | 단말기 (TTY) | 접속 지점 (IP) | 시작 시간 | 상태/종료 사유 |
|---|---|---|---|---|
prome | pts/0 | 192.168.64.1 | 3월 14일 06:59 | gone - no logout (세션 끊김) |
reboot | system boot | 6.8.0-101-generic | 3월 14일 06:59 | still running (작동 중) |
prome | pts/0 | 192.168.64.1 | 3월 1일 06:01 | crash (비정상 종료) |
reboot | system boot | 6.8.0-101-generic | 3월 1일 05:56 | still running (당시 기준) |
prome | pts/1 | 192.168.64.1 | 1월 31일 10:15 | crash (비정상 종료) |
① 시스템 크래시 (Crash) 발생
- 3월 1일과1월 31일기록에
crash표시가 있습니다. - 이는 사용자가 정상적으로
exit를 하거나shutdown명령어를 내린 것이 아니라,시스템이 강제로 꺼졌음을 의미합니다. -> 제가 가상 환경을 사용하다가 강제 종료한 적이 있기 때문에, 이때 기록된 로그입니다.
② 세션 관리 (Gone - No Logout)
- 가장 최근(3월 14일)
prome사용자의 기록을 보면 로그아웃 기록이 없습니다. -> 제가 아직 사용중인 세션입니다.
③ 커널 버전 및 기록 시점
- 시스템은 현재 Kernel 6.8.0-101-generic버전을 사용 중입니다.
- 로그 파일(
wtmp)은2026년 1월 10일부터 기록되기 시작했습니다.
3. 권장 조치 사항 (Troubleshooting) 🔗
시스템이 예상치 못하게 종료되는 이유를 확인하려면 아래 명령어를 터미널에 입력해 보세요.
- 치명적 오류 로그 확인:
sudo journalctl -p 3 -xb
2. 실패한 로그인 기록 확인 (btmp) 🔗
lastb
명령어는 /var/log/btmp
파일을 읽어옵니다.
비밀번호를 틀렸거나 존재하지 않는 계정으로 로그인을 시도한 흔적입니다.
보안상 매우 중요한 파일이므로 root
권한으로만 실행할 수 있습니다. # 실패한 접속 기록 중 최근 3개를 출력합니다.
sudo lastb -n 3 # 출력 결과 예시
# 계정명 접속장치 공격자IP 시도시간
root ssh:notty 203.0.113.50 Sat Mar 14 02:15 - 02:15 (00:00)
root ssh:notty 203.0.113.50 Sat Mar 14 02:14 - 02:14 (00:00)
admin ssh:notty 203.0.113.50 Sat Mar 14 02:14 - 02:14 (00:00)
로그를 보면 특정 IP(
203.0.113.50)에서 새벽 2시경 root
와 admin
계정으로 짧은 시간에 여러 번 로그인을 시도한 것을 볼 수 있습니다.
이는 전형적인 사전 대입 공격이나 무차별 대입 공격의 흔적입니다.
이 IP를 방화벽에서 차단하는 조치가 필요합니다.필자 기록 분석 🔗
| 시도 계정 (USER) | 단말기 (TTY) | 접속 시도 시간 | 상태 분석 |
|---|---|---|---|
root | pts/0 | 3월 14일 07:00 | 터미널 창(또는 원격)에서 관리자(root) 접속 실패 |
prome | tty1 | 3월 14일 06:59 | 로컬 콘솔(직접 연결된 키보드/모니터)에서 로그인 실패 (비밀번호 오타 등) |
UNKNOWN | tty1 | 3월 14일 06:59 | 존재하지 않는 계정명 입력 (아이디 오타 가능성) |
기존에 확인했던
last 및 journalctl 로그와 결합해 보면, 상황을 아주 명확하게 유추할 수 있습니다.- 부팅 직후의 단순 오타오늘 아침06:59에 시스템을 재부팅한 직후, 모니터 화면(tty1)에서 로그인을 시도하였습니다. 이때 아이디를 잘못 입력해
UNKNOWN이 찍혔고, 이어서prome계정의 비밀번호를 잘못 입력해 실패 기록이 남은 것으로 보입니다. - Root 접속 방어07:00에
pts/0에서root로그인이 실패한 것은,su명령어나 SSH를 통해 root 권한을 얻으려다 비밀번호를 틀렸거나 Ubuntu의 기본 보안 정책(root 직접 로그인 차단)에 의해 막힌 것입니다.
실제로 저는 오늘 아침에 시스템을 재부팅한 후, 로그인 과정에서 아이디와 비밀번호를 각각 한 번씩 오타 낸 적이 있습니다.
또한
root 계정으로 로그인하려다 비밀번호를 틀린 적도 있습니다.
따라서 이 기록들은 모두 제가 직접 로그인하는 과정에서 발생한 기록이며 잘 기록되어있는 것을 확인할 수 있습니다.시스템 로그와 rsyslog.conf 구조 🔗
접속 기록 외에 시스템의 커널 메시지, 메일 서비스 오류, 백그라운드 데몬의 상태 등 전반적인 운영 로그는
syslog
데몬이 관리합니다.
최신 리눅스에서는 기능을 확장한 rsyslog
를 주로 사용합니다.설정 파일 분석 🔗
모든 로그를 어디에, 어떻게 저장할지 결정하는 규칙은
/etc/rsyslog.conf
파일에 정의되어 있습니다.
이 파일은 크게 Facility
(시설)와 Priority
(우선순위), 그리고 Action
(행동)으로 구성됩니다. # 기본 문법: Facility.Priority Action
# 1. 커널(kern)에서 발생하는 모든(*) 로그를 커널 콘솔 파일에 저장합니다.
kern.* /dev/console
# 2. 인증(authpriv) 관련 메시지는 제외(none)하고,
# 정보(info) 수준 이상의 모든 로그를 messages 파일에 저장합니다.
*.info;authpriv.none /var/log/messages
# 3. 메일(mail) 시스템에서 발생하는 모든 로그를 제외(-)하고 버퍼링 없이 즉시 저장합니다.
mail.* -/var/log/maillog1. Facility (메시지 발생 원천) 🔗
로그를 만들어낸 프로그램의 종류입니다.
- authpriv: 사용자 인증과 관련된 보안 프로그램 (SSH 로그인 등).
- cron: 스케줄링 데몬.
- mail: 메일 시스템.
- kern: 리눅스 커널.
2. Priority (로그의 심각도) 🔗
위험한 순서부터 나열하면 다음과 같습니다. (아래로 갈수록 덜 위험함)
- emerg: 시스템이 사용 불가 상태인 치명적 오류.
- alert: 즉각적인 조치가 필요한 상태.
- crit: 하드웨어 오류 등 심각한 상태.
- err: 일반적인 에러.
- warning: 경고 메시지.
- notice: 에러는 아니지만 주의가 필요한 정상 메시지.
- info: 단순 정보성 메시지.
- debug: 프로그램 디버깅용 상세 메시지.
info
라고 적으면, info
단계뿐만 아니라 그보다 심각한 emerg
까지 모든 상위 단계의 로그
가 한 번에 기록됩니다.로그 파일의 무결성 보호 🔗
공격자가 시스템의 관리자 권한을 탈취하면 가장 먼저 하는 행동이 무엇일까요?
바로 자신의 침입 흔적이 남은 로그 파일을 지우거나 조작하는 것입니다.
삭제 시 복구 한계 🔗
wtmp
나 btmp
같은 파일은 텍스트가 아닌 바이너리로 되어 있어, 공격자가 흔적의 일부만 정교하게 삭제하기는 까다롭습니다.
하지만 공격자가 rm -rf /var/log/wtmp 명령어로 파일 전체를 날려버린다면, 로그 복구는 사실상 불가능에 가깝습니다.덧붙이기 전용 설정 (chattr) 🔗
이러한 로그 삭제를 원천적으로 방지하기 위해 파일 속성을 변경하는 방어 기법을 사용합니다.
파일에 내용 추가(Append)만 가능하고, 삭제나 덮어쓰기는 불가능하게 만드는 기술입니다.
# +a (Append Only) 속성을 부여합니다.
sudo chattr +a /var/log/wtmp
# 이제 root 권한이라도 파일을 삭제할 수 없습니다.
# 오직 시스템이 새 접속 기록을 아래에 이어 붙이는 것만 허용됩니다.결론 🔗
오늘은 시스템 침해 사고 분석의 시작점인 로그 관리에 대해 알아보았습니다.
- 바이너리 접속 로그wtmp(성공)와btmp(실패)는 텍스트 편집기가 아닌last명령어 계열로 확인해야 합니다.
- 무차별 대입 공격 식별lastb결과를 정기적으로 모니터링하여 지속적으로 실패하는 IP를 식별하고 차단해야 합니다.
- rsyslog 설정Facility(어디서)와Priority(얼마나 심각한지)의 조합으로 로그 파일의 분산 저장 위치를 유연하게 설정할 수 있습니다.
- 로그 보호삭제를 막기 위해chattr +a속성을 활용하는 것이 훌륭한 방어 전략이 됩니다.
리눅스 시스템의 내부 구조를 파악하는 여정은 여기까지입니다.
다음 시간에는
1.11 [실기] 윈도우 이벤트 로그와 침해 흔적
편을 통해 윈도우 환경에서는 이벤트 뷰어를 통해 어떻게 로그를 관리하고 분석하는지 비교해 보겠습니다.참고 🔗
- Linux Man Page: wtmp(5)↗ wtmp 파일의 바이너리 구조(C 구조체)에 대한 공식 설명 문서입니다.
- RSYSLOG Documentation↗ rsyslog 데몬의 상세한 설정 방법과 템플릿 사용법을 다루는 공식 가이드입니다.