031. Linux 서버 보안 — auditd 규칙 점검과 불변 모드

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

선행 학습

• 030. auditd 감사 정책 설계
• 38. audit.log(Linux 로그 경로 정리)

1. 개념

감사 규칙은 root라면 auditctl -D 한 줄로 지울 수 있습니다. 공격자가 root를 얻은 뒤 가장 먼저 할 수 있는 일이 바로 이것입니다. 불변 모드(immutable, -e 2) 는 이를 막기 위해 커널이 감사 설정 변경을 거부하도록 잠그는 기능입니다.

enabled 0 : 감사 꺼짐
enabled 1 : 감사 켜짐 (규칙 변경 가능)
enabled 2 : 감사 켜짐 + 잠금 → 규칙 추가/삭제, 비활성화 불가 (재부팅해야 해제)

공격자 관점의 변화
 enabled 1 → auditctl -D 로 조용히 규칙 삭제 가능
 enabled 2 → 규칙 삭제 실패 → 재부팅 필요 → 재부팅 자체가 눈에 띄는 이벤트

2. 왜 중요한가

• 불변 모드는 공격자가 흔적 없이 감사를 끄는 것을 어렵게 만듭니다. 우회하려면 재부팅이 필요하고, 재부팅은 서비스 중단·부팅 로그·SIEM 수신 공백으로 드러납니다.
• 운영자도 규칙을 바꾸려면 재부팅해야 하므로, 변경 절차와 함께 도입해야 합니다.
• auditd 데몬 중지·규칙 변경 시도 자체가 로그로 남아 하드닝 해제 탐지의 핵심 근거가 됩니다(039편).

3. 핵심 명령어 / 설정

명령	용도
sudo auditctl -s	enabled 값(0/1/2), lost, backlog
-e 2 (rules.d 마지막 파일)	부팅 시 규칙 로드 후 잠금
sudo auditctl -l	현재 규칙
sudo ausearch -m CONFIG_CHANGE -i	감사 설정 변경 이력
sudo ausearch -m DAEMON_END,DAEMON_START -i	auditd 종료/시작 이력

Rocky의 auditd.service는 RefuseManualStop=yes라 systemctl stop auditd가 거부되며, 중지하려면 service auditd stop을 써야 합니다. 이 차이도 탐지 포인트가 됩니다.

4. 실습 (실습 예시)

# 1) 불변 모드 파일을 가장 마지막 순서로 추가
echo '-e 2' | sudo tee /etc/audit/rules.d/99-finalize.rules
sudo augenrules --load
sudo auditctl -s | grep enabled          # enabled 2

# 2) 잠금 동작 확인 (테스트 VM)
sudo auditctl -D                          # 실패해야 정상
sudo auditctl -w /tmp/test -p w -k t      # 실패해야 정상

# 3) 규칙 개수 기준선 저장
sudo auditctl -l | sha256sum | sudo tee /root/baseline/audit_rules.sha256

규칙을 수정해야 할 때는 rules.d 파일을 고친 뒤 계획된 재부팅으로 적용하고, 그 일정을 변경관리 기록에 남깁니다.

5. 정상 상태

$ sudo auditctl -s | grep enabled
enabled 2
$ sudo auditctl -D
Error sending delete all request (Operation not permitted)

6. 이상 상태

$ sudo auditctl -s | grep enabled
enabled 1
$ ls /etc/audit/rules.d/
10-base.rules  30-identity.rules  40-exec.rules
$ journalctl --list-boots --no-pager | tail -1
  0 4c2e...  Thu 2026-10-01 03:20:05 KST—...

• 99-finalize.rules가 삭제되어 잠금이 풀린 상태
• 직전에 새벽 재부팅 → 파일 삭제 후 재부팅으로 잠금 해제 → 규칙 수정 흐름 의심 (028편의 journal volatile 전환과 같은 시각대라면 동일 행위로 묶어 분석)

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

불변 모드 환경에서의 변경 시도와 auditd 중지 흔적입니다(가상의 예시 로그).

type=CONFIG_CHANGE msg=audit(1759733000.110:2501): auid=1002 ses=12 subj=unconfined_u:unconfined_r:unconfined_t:s0 op=remove_rule key="root_exec" list=4 res=0
type=CONFIG_CHANGE msg=audit(1759733002.330:2502): op=set audit_enabled=0 old=2 auid=1002 ses=12 res=0
type=DAEMON_END msg=audit(1759733060.000:2510): op=terminate auid=1002 uid=0 ses=12 pid=1 subj=system_u:system_r:init_t:s0 res=success

필드	해석
op=remove_rule ... res=0	규칙 삭제 시도, 실패(불변 모드로 차단)
audit_enabled=0 old=2 res=0	감사 비활성화 시도 실패
DAEMON_END op=terminate	auditd 데몬 종료(커널 감사는 유지되나 기록 데몬이 멈춤)

res=0(실패) 이벤트도 "누군가 감사를 끄려고 했다" 는 강력한 증거입니다. 실패했다고 무시하면 안 됩니다.

8. SOC 관제 포인트

• CONFIG_CHANGE는 성공·실패 모두 높은 우선순위로 수집합니다.
• enabled 값이 2가 아닌 서버를 정기 점검으로 찾아냅니다.
• auditd 종료 후에는 서버 로그가 끊길 수 있으므로, SIEM에서 audit 이벤트 수신 공백을 함께 감시합니다.

9. 탐지 규칙

<group name="local,audit_tamper,">
  <rule id="100370" level="12">
    <if_group>audit</if_group>
    <match>type=CONFIG_CHANGE</match>
    <regex>op=remove_rule|audit_enabled=0|op=remove_dir</regex>
    <description>감사 규칙 삭제/감사 비활성화 시도</description>
  </rule>
  <rule id="100371" level="12">
    <if_group>audit</if_group>
    <match>type=DAEMON_END</match>
    <description>auditd 데몬 종료</description>
  </rule>
</group>

Wazuh 기본 룰셋에도 auditd 설정 변경·데몬 종료 관련 룰이 있으므로, 기본 룰 ID와 레벨을 wazuh-logtest로 확인한 뒤 부족한 조건만 위와 같이 보완합니다.

10. 대응 방법

1. 초기 확인 — auditctl -s/-l 상태와 CONFIG_CHANGE·DAEMON_END 이벤트의 사용자·시각을 확인합니다.
2. 범위 확인 — 같은 세션의 다른 행위와, 감사 공백 기간의 다른 로그원(journal, FIM, 원격 syslog)을 확인합니다.
3. 증거 확보 — audit.log 원본(원격 사본 포함), rules.d 사본, 부팅 기록을 보존합니다.
4. 차단/조치 — rules.d 복원 후 계획된 재부팅으로 enabled 2를 재적용하고, 관련 계정을 차단합니다.
5. 재발 방지 — 불변 모드를 표준 정책으로 적용하고 enabled 값을 정기 점검합니다.

11. 핵심 정리

구분	핵심 내용
enabled 값	0 꺼짐 · 1 켜짐 · 2 켜짐+잠금
불변 모드	rules.d 마지막 파일에 -e 2, 해제는 재부팅만 가능
변조 로그	CONFIG_CHANGE (op=remove_rule, audit_enabled=0, res=0/1)
데몬 중지	DAEMON_END, Rocky는 systemctl stop 거부
면접 포인트	"res=0 실패 이벤트도 감사 무력화 시도의 증거"

12. 다음 편 예고

다음 편 032. Linux 서버 보안 — NTP(chrony) 시간 동기화 보안 에서는 모든 로그 분석의 기준이 되는 NTP(chrony) 시간 동기화 보안을 다룹니다.

---

이전 편: 030. Linux 서버 보안 — auditd 감사 정책 설계
📚 시리즈 전체 보기: 시스템 보안 · 취약점