대상 OS: Debian 12 (bookworm)

침해사고 대응에서 가장 먼저 흔들리는 건 ‘증거’입니다.
공격자는 흔히 로그부터 지우거나, 조용히 바꿔치기 하거나, 아예 로깅을 꺼버리려 합니다.
그래서 좋은 로깅은 “많이 남기는 것”보다 “나중에 믿을 수 있는 형태로 남기는 것”에 가깝습니다.
Debian 12의 systemd-journald에는 Forward Secure Sealing(FSS)이라는 기능이 있어, 로그가 사후에 변조되면 흔적이 남도록 설계할 수 있습니다.

이 글은 Debian 12에서 journald FSS를 켜고, 실제로 무결성을 검증하는 방법과 중앙 로그 수집으로 넘기기 전에 점검해야 할 운영 체크리스트를 정리합니다.

---

1) Forward Secure Sealing(FSS)이 뭐길래 중요한가

1) 로그 파일이 나중에 수정/삭제되면 “무언가 이상하다”는 검증 근거를 남긴다

2) 단순 파일 권한 보호(읽기/쓰기 제한)보다 한 단계 강한 ‘사후 검증’을 제공한다

3) 로컬 디스크에 있는 로그의 신뢰도를 높여, IR(Incident Response)에서 시간을 절약한다

주의
- FSS는 “로그 위변조를 불가능하게” 만드는 기능이 아닙니다.
- 공격자가 루트 권한을 가진 상태에서 로그를 삭제하는 건 여전히 가능합니다.
- 하지만 “변조/누락을 검출할 수 있는 근거”를 남기는 것만으로도 대응 품질이 달라집니다.

---

2) 변경 전 확인: journald 설정/저장 형태

1) journald가 persistent 저장인지 확인

sudo grep -R "^Storage=" -n /etc/systemd/journald.conf /etc/systemd/journald.conf.d 2>/dev/null || true

2) 현재 journal 경로 확인

sudo ls -ld /var/log/journal 2>/dev/null || echo "no persistent journal dir"

3) journald 상태 확인

systemctl status systemd-journald --no-pager

---

3) journald를 persistent로 전환(권장)

FSS를 실전적으로 쓰려면 journal이 재부팅 후에도 남는(persistent) 구성이 보통 유리합니다.

1) persistent 디렉터리 생성

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo chown root:systemd-journal /var/log/journal
sudo chmod 2755 /var/log/journal

2) Storage=persistent 설정

sudo mkdir -p /etc/systemd/journald.conf.d
sudo tee /etc/systemd/journald.conf.d/10-persistent.conf >/dev/null