41. Linux 보안 로그 구조

Linux 시스템 보안 기초 · 41/50편

이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다.

선행 학습

• 리눅스 시스템 기초 — Linux 로그와 journalctl
• 서비스 · 프로세스 관리 — journalctl로 서비스 로그 분석

1. 들어가며

탐지와 대응의 모든 것은 로그에서 출발합니다. '증거는 거짓말하지 않는다'는 원칙의 실체가 바로 로그죠. 그런데 리눅스 로그는 journald, rsyslog, auditd가 얽혀 있어 헷갈립니다. 이번 편은 그 관계를 명확히 정리합니다.

2. 핵심 개념

세 로그 시스템의 역할:

journald가 대부분을 수집하고, rsyslog가 텍스트 파일·원격 전송을, auditd가 저수준 감사를 담당합니다.

        커널 / 서비스 / 애플리케이션
                  │
        ┌─────────┼──────────┐
        ▼         ▼          ▼
    journald   rsyslog     auditd
  (systemd    (텍스트,    (syscall
   저널)       원격전송)    감사)
        │         │          │
        ▼         ▼          ▼
   journalctl  /var/log/*  /var/log/audit

3. 동작 원리

systemd 시스템에서는 journald가 커널·서비스 로그를 먼저 받아 저널(바이너리)에 저장하고, 설정에 따라 rsyslog로 전달해 텍스트 파일로도 남깁니다. auditd는 커널 감사 서브시스템에 직접 연결되어, syscall 수준의 상세 이벤트(누가 어떤 파일을 열었나 등, 43편)를 기록합니다.

배포판 차이가 큰 영역입니다:

• Ubuntu/Debian: SSH 등 인증 로그가 /var/log/auth.log
• RHEL/Rocky: 인증 로그가 /var/log/secure

이 차이를 모르면 로그를 못 찾아 헤맵니다.

4. 명령어 실습

# journald: 서비스/우선순위별
sudo journalctl -u ssh -p warning --since today

# rsyslog 텍스트 로그 (배포판 차이)
sudo tail /var/log/auth.log    # Ubuntu/Debian
sudo tail /var/log/secure      # RHEL/Rocky

# auditd 상태와 로그
sudo auditctl -s; sudo tail /var/log/audit/audit.log

5. 실행 결과

실습 컨테이너에서 로그 인프라를 실제로 구동해 확인한 결과입니다. (실제 캡처)

$ ls /var/log/ | grep -E 'auth|audit|syslog'
audit
auth.log
syslog

$ sudo auditctl -s
enabled 1
pid 1501

Ubuntu 계열이라 인증 로그는 auth.log이며, auditd가 enabled 1로 동작 중입니다. RHEL 계열이었다면 auth.log 대신 secure를 봐야 합니다 — 이 차이가 실무에서 매우 중요합니다.

6. 보안 관점 — 정상 사용 vs 악용

• 정상: 로그가 정상 수집·보존되고, 원격(중앙)으로도 전송됨.
• 위험/침해 징후:
  • 로그가 갑자기 비거나 삭제됨(anti-forensics)
  • auditd가 중지됨
  • 로그 시간대의 공백(공격자가 특정 구간 삭제)

공격자는 흔적을 지우려 로그를 조작합니다. 그래서 로그의 원격 전송·보존이 신뢰성의 핵심입니다 — 로컬 로그는 지워질 수 있지만 중앙 서버로 이미 전송된 로그는 남습니다.

7. 탐지 방법

• 로그 존재·연속성 점검(시간 공백 탐지)
• auditd 동작 상태 확인
• 원격 전송(rsyslog forwarding) 설정 확인

8. SOC 관점 — SIEM · Wazuh · IOC

SOC의 전제는 '신뢰할 수 있는 로그'입니다. 그래서 로그를 SIEM(중앙)으로 실시간 전송해, 로컬 삭제에도 증거가 남게 합니다. 사용자의 실습 환경(ELK/Wazuh + Suricata)이 바로 이 중앙 수집 구조입니다. journald·rsyslog·auditd를 모두 수집해야 인증·시스템·syscall을 빠짐없이 봅니다.

9. 실습 체크리스트

[ ] journald/rsyslog/auditd 역할 구분
[ ] 배포판별 인증 로그 위치 확인(auth.log vs secure)
[ ] auditd 동작 상태 확인
[ ] 원격 로그 전송 설정 확인

10. 핵심 정리

• 탐지·대응의 모든 것은 로그에서 출발한다.
• journald(수집)·rsyslog(텍스트/전송)·auditd(syscall)가 역할을 나눈다.
• 인증 로그는 Ubuntu auth.log, RHEL secure로 다르다.
• 공격자는 로그를 지우므로 원격 전송·보존이 핵심이다.
• SIEM 중앙 수집이 로그 신뢰성을 보장한다.

11. 다음 편

다음 편에서는 42. journalctl 보안 분석 를 다룹니다. journald를 다루는 journalctl로 보안 이벤트를 분석하는 실무 기법을 봅니다.

본 실습은 격리된 테스트 VM(Rocky Linux / Ubuntu, VMware) 및 테스트 계정 환경을 기준으로 하며, 운영 서버를 대상으로 하지 않습니다. 실행 결과는 실제 캡처와 예시 출력을 명확히 구분해 표기합니다.