028. Linux 서버 보안 — journald 보존·저장 설정 점검

시스템 보안 · 취약점 › A. Linux 서버 보안 설정 · 28/50편 (전체 028/450)
학습 단계: 2단계 · 설정 및 점검
실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」이며, IP·계정·호스트명은 가상의 값입니다.

선행 학습

• 31. journald(Linux 로그 경로 정리)
• 42. journalctl 보안 분석

1. 개념

journald는 systemd 환경에서 커널·서비스·인증 로그를 모으는 1차 수집기입니다. 저장 방식에 따라 재부팅 후 로그가 남는지가 결정됩니다.

Storage=	저장 위치	재부팅 후
persistent	/var/log/journal/	유지
volatile	/run/log/journal/ (메모리)	삭제
auto(기본)	/var/log/journal/이 있으면 persistent, 없으면 volatile	디렉터리 존재 여부에 따름
none	저장 안 함(전달만)	-

서비스/커널 로그 → journald ─┬─ journal 파일 (Storage 설정)
                             └─ ForwardToSyslog=yes → rsyslog → /var/log/* , 원격 전송

2. 왜 중요한가

• 침해 분석에서 "재부팅 전 로그가 없다"는 것은 치명적입니다. volatile이면 공격자가 서버를 재부팅하는 것만으로 흔적이 사라집니다.
• 용량 제한(SystemMaxUse)이 너무 작으면 대량 이벤트(무차별 대입 등) 발생 시 오래된 증거가 자동으로 밀려납니다.
• journalctl --vacuum-*, --rotate는 관리 명령이지만 증거 삭제에도 그대로 쓰일 수 있습니다(G영역에서 상세 분석).

3. 핵심 명령어 / 설정

설정(/etc/systemd/journald.conf 또는 journald.conf.d/*.conf)	의미
Storage=persistent	디스크 저장 강제
SystemMaxUse=1G	journal 최대 사용 용량
MaxRetentionSec=3month	보존 기간 상한
ForwardToSyslog=yes	rsyslog로 전달(원격 전송 경로 확보)
Compress=yes	압축 저장
Seal=yes + journalctl --setup-keys	FSS(Forward Secure Sealing) 변조 검증

점검 명령	용도
journalctl --disk-usage	현재 사용량
journalctl --list-boots	보존된 부팅 기록(persistent 여부 확인)
systemd-analyze cat-config systemd/journald.conf	실효 설정(드롭인 포함)
journalctl --verify	journal 파일 무결성 검사

4. 실습 (실습 예시)

# 1) 현재 상태
journalctl --list-boots --no-pager | tail -3
journalctl --disk-usage
ls -ld /var/log/journal /run/log/journal 2>&1
systemd-analyze cat-config systemd/journald.conf | grep -vE '^#|^$'

# 2) persistent + 보존 정책 drop-in
sudo mkdir -p /etc/systemd/journald.conf.d
sudo tee /etc/systemd/journald.conf.d/10-retention.conf <<'EOF'
[Journal]
Storage=persistent
SystemMaxUse=1G
MaxRetentionSec=3month
ForwardToSyslog=yes
EOF
sudo systemctl restart systemd-journald

# 3) 무결성 검사
sudo journalctl --verify 2>&1 | tail -3

배포판·설치 방식에 따라 기본 저장 방식이 다르므로, 반드시 --list-boots로 이전 부팅 로그가 실제로 남아 있는지 실측합니다.

5. 정상 상태

$ journalctl --list-boots --no-pager | tail -3
 -2 5a1c...  Sat 2026-09-26 09:00:11 KST—Sun 2026-09-27 18:02:40 KST
 -1 9d03...  Mon 2026-09-28 08:58:02 KST—Wed 2026-09-30 19:11:05 KST
  0 e7b2...  Thu 2026-10-01 08:55:31 KST—Thu 2026-10-01 13:20:12 KST
$ journalctl --disk-usage
Archived and active journals take up 312.0M in the file system.

여러 부팅 기록이 이어져 있고, 사용량이 상한보다 여유 있는 상태가 정상입니다.

6. 이상 상태

$ journalctl --list-boots --no-pager
  0 e7b2...  Thu 2026-10-01 03:20:05 KST—Thu 2026-10-01 13:20:12 KST
$ systemd-analyze cat-config systemd/journald.conf | grep -i storage
Storage=volatile
$ ls -l /etc/systemd/journald.conf.d/
-rw-r--r--. 1 root root 27 Oct  1 03:15 00-perf.conf

• 부팅 기록이 현재 부팅 하나뿐, 시작이 03:20(새벽 재부팅) → 그 이전 로그 소실
• 03:15에 Storage=volatile drop-in 생성 → 재부팅으로 기록을 지우기 위한 사전 작업 가능성
• 원격 SIEM에 전송된 사본이 있다면 소실 구간을 복원할 수 있습니다(029편).

7. 로그 분석 (분석 방법)

journal 삭제·설정 변경 흔적입니다(가상의 예시 로그). 로컬 journal이 지워질 수 있으므로 원격 수집본에서 확인하는 것이 원칙입니다.

type=EXECVE msg=audit(1759732500.200:2301): argc=2 a0="journalctl" a1="--vacuum-time=1s"
type=PATH msg=audit(1759732440.010:2297): item=1 name="/etc/systemd/journald.conf.d/00-perf.conf" nametype=CREATE key="journald_conf"
Oct  1 03:15:41 rocky9-web01 systemd-journald[612]: Journal stopped
Oct  1 03:15:41 rocky9-web01 systemd-journald[8801]: Journal started
Oct  1 03:15:41 rocky9-web01 systemd-journald[8801]: Runtime Journal (/run/log/journal/...) is 8.0M, max 76.5M, 68.5M free.

관찰	해석
--vacuum-time=1s	1초보다 오래된 journal 모두 삭제
00-perf.conf 생성	성능 설정처럼 위장한 저장 방식 변경
Runtime Journal (/run/...)	journald가 휘발성 저장으로 재시작됨

8. SOC 관제 포인트

• journalctl --vacuum-*, --rotate, --flush 실행과 journald 설정 변경을 모두 수집합니다.
• --list-boots 결과의 부팅 기록 수 급감을 지표로 사용합니다.
• 서버 로컬 로그는 지워질 수 있다는 전제로, 원격 전송(rsyslog/Wazuh)을 필수 구성으로 둡니다.

9. 탐지 규칙

-w /etc/systemd/journald.conf   -p wa -k journald_conf
-w /etc/systemd/journald.conf.d/ -p wa -k journald_conf
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/journalctl -k journalctl_exec

<rule id="100340" level="12">
  <if_group>audit</if_group>
  <field name="audit.key">journalctl_exec</field>
  <match>--vacuum|--rotate</match>
  <description>journal 삭제/회전 명령 실행</description>
</rule>

정기 관리 작업(예: 사내 정리 스크립트)이 --vacuum을 쓴다면 실행 계정·시각을 예외 조건으로 정의해 오탐을 줄입니다.

10. 대응 방법

1. 초기 확인 — journald 실효 설정·부팅 기록·journal 파일 목록을 확인합니다.
2. 범위 확인 — 원격 SIEM에서 로컬에 없는 구간의 로그가 있는지 확인합니다.
3. 증거 확보 — 남아 있는 journal 파일 사본과 --verify 결과, audit 로그를 보존합니다.
4. 차단/조치 — persistent 설정을 복원하고 비인가 설정 파일을 격리합니다.
5. 재발 방지 — journald 보존 정책을 표준화하고 vacuum·설정 변경 탐지 룰을 운영합니다.

11. 핵심 정리

구분	핵심 내용
Storage	persistent(/var/log/journal) vs volatile(/run, 재부팅 시 소멸)
보존 설정	SystemMaxUse, MaxRetentionSec, ForwardToSyslog
점검 명령	journalctl --list-boots, --disk-usage, --verify
위험 신호	volatile 전환, --vacuum-time 실행, 부팅 기록 급감
면접 포인트	"로컬 로그는 지워질 수 있다 → 원격 전송이 전제"

12. 다음 편 예고

다음 편 029. Linux 서버 보안 — rsyslog 설정 점검과 원격 전송 에서는 journald에서 넘겨받은 로그를 파일·원격으로 보내는 rsyslog 설정 점검과 원격 전송을 다룹니다.

---

이전 편: 027. Linux 서버 보안 — systemd 서비스 보안 옵션과 systemd-analyze security
📚 시리즈 전체 보기: 시스템 보안 · 취약점