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

선행 학습

1. 개념

앞선 편들에서 sshd_config, sudoers.d, /tmp 실행 등 규칙을 하나씩 추가했습니다. 운영에서는 이것을 감사 정책(audit policy) 이라는 하나의 설계로 정리해야 유지보수와 SIEM 연계가 가능합니다.

감사 정책 설계 순서
① 무엇을 볼 것인가     → 감시 목적 분류 (계정, 인증, 권한, 실행, 시스템 설정)
② 어떻게 볼 것인가     → 파일 감시(-w) vs 시스템 콜 규칙(-a)
③ 어떻게 이름 붙일까   → 키(-k) 명명 규칙 → SIEM 룰이 키로 매칭
④ 얼마나 남길까        → 성능·저장 용량 고려해 범위 축소(auid, arch, path 조건)
⑤ 어떻게 지킬까        → 불변 모드(-e 2), 원격 전송 (031편)

2. 왜 중요한가

  • 규칙이 많기만 하고 체계가 없으면 로그 폭증 → 디스크 고갈 → 중요한 이벤트 유실로 이어집니다.
  • 키 이름이 일관되면 SIEM 룰을 audit.key 하나로 만들 수 있어 탐지 룰 관리가 단순해집니다.
  • 감사 정책은 "무엇을 탐지할 것인가"라는 SOC 요구사항을 서버 설정으로 번역한 결과물입니다.

3. 핵심 명령어 / 설정

목적규칙 예시키
계정 파일-w /etc/passwd -p wa, -w /etc/shadow -p wa, -w /etc/group -p waidentity
인증 설정-w /etc/pam.d/ -p wa, -w /etc/ssh/sshd_config.d/ -p waauth_conf
권한 설정-w /etc/sudoers -p wa, -w /etc/sudoers.d/ -p wapriv_conf
root 실행-a always,exit -F arch=b64 -S execve -F euid=0 -F auid>=1000 -F auid!=unsetroot_exec
시간 변경-a always,exit -F arch=b64 -S adjtimex,settimeofday,clock_settimetime_change
커널 모듈-a always,exit -F arch=b64 -S init_module,finit_module,delete_modulekmod
네트워크 설정-a always,exit -F arch=b64 -S sethostname,setdomainname, -w /etc/hosts -p wanet_conf
예약 작업-w /etc/cron.d/ -p wa, -w /var/spool/cron/ -p wacron_change
서비스-w /etc/systemd/system/ -p wasystemd_units

32비트 호환 시스템 콜 우회를 막으려면 -a 규칙은 arch=b32 버전도 함께 둡니다.

4. 실습 (실습 예시)

# /etc/audit/rules.d/ 아래 목적별 파일로 분리 → 번호로 로드 순서 관리
sudo tee /etc/audit/rules.d/10-base.rules <<'EOF'
-D
-b 8192
-f 1
EOF
sudo tee /etc/audit/rules.d/30-identity.rules <<'EOF'
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group  -p wa -k identity
-w /etc/gshadow -p wa -k identity
EOF
sudo tee /etc/audit/rules.d/40-exec.rules <<'EOF'
-a always,exit -F arch=b64 -S execve -F euid=0 -F auid>=1000 -F auid!=unset -k root_exec
-a always,exit -F arch=b32 -S execve -F euid=0 -F auid>=1000 -F auid!=unset -k root_exec
EOF

# 병합·적용·확인
sudo augenrules --check
sudo augenrules --load
sudo auditctl -l | head
sudo auditctl -s | grep -E 'enabled|backlog_limit|lost'

-b 8192는 커널 버퍼 크기, -f 1은 버퍼 초과 등 실패 시 커널 메시지(printk)를 남기는 모드입니다(-f 2는 패닉이라 운영 서버에 부적합).

5. 정상 상태

$ sudo auditctl -s | grep -E 'enabled|backlog_limit|lost'
enabled 1
backlog_limit 8192
lost 0
$ sudo auditctl -l | grep -c -- '-k '
24

lost 0(유실 없음)이고, 규칙이 정책 문서의 개수·키와 일치하는 상태가 정상입니다.

6. 이상 상태

$ sudo auditctl -s | grep -E 'enabled|lost'
enabled 1
lost 18342
$ sudo auditctl -l
No rules
  • lost 값이 크게 증가 → 버퍼 부족 또는 과도한 규칙으로 이벤트 유실 발생
  • 규칙이 하나도 없음 → auditctl -D로 삭제됐거나 rules.d 파일이 제거된 상태 (031편 불변 모드로 방지)

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

키를 기준으로 검색하면 목적별 이벤트를 바로 꺼낼 수 있습니다(가상의 예시 로그).

$ sudo ausearch -k root_exec -i --start today | tail -4
type=PROCTITLE msg=audit(10/01/2026 03:20:11.402:2401) : proctitle=cat /etc/shadow
type=SYSCALL msg=audit(10/01/2026 03:20:11.402:2401) : arch=x86_64 syscall=execve success=yes exit=0 ppid=9101 pid=9120 auid=devops uid=root euid=root tty=pts1 ses=12 comm=cat exe=/usr/bin/cat key=root_exec
$ sudo aureport -k --summary --start today
Key Summary Report
===========================
total  key
===========================
412  root_exec
31   systemd_units
6    identity
도구용도
ausearch -k 키 -i키별 이벤트, -i로 UID·시스템 콜 이름 해석
aureport -k --summary키별 건수 → 평소 대비 급증 확인
proctitle실행된 명령줄 전체

8. SOC 관제 포인트

  • 감사 정책 문서(규칙·키·목적)를 SIEM 룰 문서와 같은 키 이름으로 관리합니다.
  • auditctl -s의 lost, backlog 값을 정기 수집해 유실 여부를 감시합니다.
  • aureport -k --summary로 키별 건수의 평소 패턴(baseline)을 만들어 급증을 탐지합니다.

9. 탐지 규칙

<!-- 키 기반 단일 패턴: 키 이름만 바꿔 여러 룰을 일관되게 운영 -->
<group name="local,audit_policy,">
  <rule id="100360" level="8">
    <if_group>audit</if_group>
    <field name="audit.key">identity|priv_conf|auth_conf</field>
    <description>계정/권한/인증 설정 변경: $(audit.key)</description>
  </rule>
  <rule id="100361" level="10">
    <if_group>audit</if_group>
    <field name="audit.key">kmod|time_change</field>
    <description>커널 모듈 또는 시스템 시간 변경: $(audit.key)</description>
  </rule>
</group>

Kibana에서는 data.audit.key : * 집계로 키별 이벤트 추이를 대시보드화할 수 있습니다.

10. 대응 방법

  1. 초기 확인 — 정책 대비 누락·추가된 규칙과 lost 값을 확인합니다.
  2. 범위 확인 — 규칙이 사라진 기간 동안 다른 로그원(journal, FIM, 원격 syslog)으로 공백을 보완합니다.
  3. 증거 확보 — auditctl -l, auditctl -s 출력, rules.d 사본, audit.log를 보존합니다.
  4. 차단/조치 — augenrules --load로 정책을 재적용하고 버퍼·규칙 범위를 조정합니다.
  5. 재발 방지 — 감사 정책을 문서화하고 키 기반 SIEM 룰·건수 기준선을 운영합니다.

11. 핵심 정리

구분핵심 내용
설계 순서목적 → 방식(-w/-a) → 키 → 범위 → 보호
키 명명identity, priv_conf, auth_conf, root_exec, kmod, time_change ...
적용/etc/audit/rules.d/*.rules → augenrules --load
상태 지표auditctl -s 의 lost, backlog
면접 포인트"감사 정책 = SOC 탐지 요구사항을 서버 설정으로 번역한 것"

12. 다음 편 예고

다음 편 031. Linux 서버 보안 — auditd 규칙 점검과 불변 모드 에서는 설계한 규칙이 삭제·변경되지 않도록 지키는 불변 모드와 규칙 점검을 다룹니다.


이전 편: 029. Linux 서버 보안 — rsyslog 설정 점검과 원격 전송
📚 시리즈 전체 보기: 시스템 보안 · 취약점

profile
코드에 숨겨진 위협을 읽고 AI로 보안의 미래를 설계합니다. 프론트엔드 개발 경험을 자산 삼아 더 견고하고 지능적인 보안 운영 시스템을 구축해 나가는 과정을 기록합니다

0개의 댓글