045. Linux 서버 보안 — Wazuh SCA로 설정 준수 모니터링

changseop lee·5일 전

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

선행 학습

1. 개념

Wazuh SCA 는 에이전트가 정책 파일(YAML)에 정의된 점검을 주기적으로 실행하고, 결과를 관리 서버로 보내는 기능입니다. 041~044편에서 다룬 "기준 점검"을 모든 서버에서 상시·중앙 집중적으로 운영하는 방법입니다.

[에이전트]                                      [관리 서버 / 대시보드]
 /var/ossec/ruleset/sca/*.yml (기본 정책)
 /var/ossec/etc/shared/... 또는 지정 경로 (커스텀)
        ↓ interval 마다 점검 실행
 check 결과: passed / failed / not applicable
        ↓ 이전 결과와 달라진 항목 전송          → Configuration Assessment 화면
                                                → 상태 변화 Alert (sca 그룹 룰)

기본 제공 정책은 배포판별 CIS 벤치마크를 기반으로 하며, 에이전트 OS에 맞는 정책이 자동 적용됩니다(파일명·지원 범위는 Wazuh 버전별로 확인).

2. 왜 중요한가

  • 정기 점검 도구(OpenSCAP·Lynis)는 실행 시점의 스냅샷이지만, SCA는 주기적으로 반복되어 변화 시점을 좁혀 줍니다.
  • 결과가 SIEM과 같은 플랫폼에 모이므로, 설정 변화(SCA)와 행위 로그(auditd·인증)를 한 화면에서 연결할 수 있습니다.
  • 커스텀 정책으로 조직 고유 기준(역할별 포트, 관제 에이전트 설정)을 같은 체계에 넣을 수 있습니다.

3. 핵심 명령어 / 설정

SCA 정책 YAML의 기본 구조입니다.

요소의미
policy:id, name, description
requirements:정책 적용 조건(이 조건이 맞는 시스템만 점검)
checks:점검 항목 목록(id, title, rationale, remediation, condition, rules)
condition:all / any / none — rules 결과 결합 방식
규칙 접두어f: 파일, d: 디렉터리, p: 프로세스, c: 명령 출력, r: 레지스트리(Windows)
연산자-> 내용 검사, r: 정규식, ! 부정, n: 숫자 비교

4. 실습 (실습 예시)

# /var/ossec/etc/custom-sca/syssec_baseline.yml (커스텀 정책 예시)
policy:
  id: "syssec_baseline"
  name: "SysSec Linux baseline (lab)"
  description: "시스템 보안 · 취약점 시리즈 A영역 핵심 항목"
requirements:
  title: "Linux 시스템"
  condition: any
  rules:
    - 'f:/etc/os-release'
checks:
  - id: 90001
    title: "SSH root 직접 로그인 차단"
    remediation: "sshd_config.d에 PermitRootLogin no 설정 후 reload"
    condition: all
    rules:
      - 'c:sshd -T -> r:^permitrootlogin\s+no'
  - id: 90002
    title: "감사 설정 불변 모드"
    condition: all
    rules:
      - 'c:auditctl -s -> r:^enabled\s+2'
  - id: 90003
    title: "IP 포워딩 비활성화"
    condition: all
    rules:
      - 'f:/proc/sys/net/ipv4/ip_forward -> r:^0$'
<!-- 에이전트 ossec.conf -->
<sca>
  <enabled>yes</enabled>
  <scan_on_start>yes</scan_on_start>
  <interval>12h</interval>
  <policies>
    <policy>/var/ossec/etc/custom-sca/syssec_baseline.yml</policy>
  </policies>
</sca>

c:(명령 실행) 규칙은 보안상 기본 비활성화되어 있어, 에이전트 local_internal_options.conf에 sca.remote_commands=1 설정이 필요합니다(로컬 정책 파일이면 버전에 따라 동작이 다르므로 문서 확인).

5. 정상 상태

[Configuration Assessment] rocky9-web01
Policy: SysSec Linux baseline (lab)     Passed: 3  Failed: 0  Not applicable: 0  Score: 100%
Policy: CIS Benchmark (배포판 정책)      Passed: 158 Failed: 21 ...

커스텀 정책은 모두 Passed, 기본 CIS 정책의 Failed는 승인된 예외 목록과 일치하는 상태가 정상입니다(수치는 예시).

6. 이상 상태

Policy: SysSec Linux baseline (lab)     Passed: 1  Failed: 2  Score: 33%
  90001 SSH root 직접 로그인 차단   passed → failed
  90002 감사 설정 불변 모드          passed → failed

SCA는 상태가 바뀐 항목을 이벤트로 보내므로, passed → failed 전환 자체가 "그 사이에 설정이 바뀌었다"는 증거입니다. 전환이 감지된 스캔 시각과 직전 스캔 시각 사이가 변경 발생 구간입니다.

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

SCA 상태 변화 Alert의 형태와 주요 필드입니다(가상의 예시, 필드명은 Wazuh 버전별로 확인).

rule.groups: sca
rule.description: SysSec Linux baseline (lab): SSH root 직접 로그인 차단: Status changed from passed to failed
agent.name: rocky9-web01
data.sca.policy: SysSec Linux baseline (lab)
data.sca.check.id: 90001
data.sca.check.result: failed
data.sca.check.previous_result: passed
timestamp: 2026-10-01T02:30:11+0900
필드분석 활용
check.result / previous_result상태 전환 방향
timestamp변화를 감지한 스캔 시각(변경 시각 아님)
check.id정책 문서·조치 방법과 연결

정확한 변경 시각은 같은 에이전트의 auditd 이벤트(038편)로 좁힙니다. SCA는 "무엇이", auditd는 "언제·누가"를 담당합니다.

8. SOC 관제 포인트

  • SCA passed → failed 전환은 하드닝 해제(039편) 룰과 같은 그룹으로 묶어 상관 분석합니다.
  • 스캔 주기가 길수록 변경 구간이 넓어지므로, 핵심 항목은 auditd·FIM으로 실시간 보완합니다.
  • 대시보드의 점수보다 최근 전환 항목 목록을 우선 확인합니다.

9. 탐지 규칙

<!-- SCA 이벤트 중 커스텀 정책 failed 전환 상향 (부모 SCA 룰 ID는 wazuh-logtest로 확인 후 if_sid 지정 권장) -->
<group name="local,sca,hardening_drift,">
  <rule id="100500" level="10">
    <if_group>sca</if_group>
    <field name="sca.policy">SysSec Linux baseline</field>
    <field name="sca.check.result">failed</field>
    <description>SysSec 기준 항목 실패 전환: $(sca.check.title)</description>
  </rule>
</group>

Kibana KQL: rule.groups : "sca" and data.sca.check.result : "failed" and data.sca.check.previous_result : "passed"

10. 대응 방법

  1. 초기 확인 — 전환된 항목과 직전 스캔·현재 스캔 시각으로 변경 구간을 확인합니다.
  2. 범위 확인 — 같은 항목이 전환된 다른 에이전트, 같은 구간의 auditd·인증 Alert를 조회합니다.
  3. 증거 확보 — SCA 결과 이벤트와 해당 구간 원본 로그를 보존합니다.
  4. 차단/조치 — 설정을 복원하고 다음 스캔에서 passed로 돌아오는지 확인합니다.
  5. 재발 방지 — 커스텀 정책을 버전 관리하고 전환 Alert를 하드닝 use case에 포함합니다.

11. 핵심 정리

구분핵심 내용
동작에이전트가 YAML 정책 주기 실행 → 상태 변화 전송
규칙 문법f: 파일, c: 명령, p: 프로세스, -> r: 정규식, condition all/any/none
핵심 지표passed → failed 전환
한계timestamp는 감지 시각 → 변경 시각은 auditd로
면접 포인트"SCA는 무엇이 바뀌었나, auditd는 언제·누가"

12. 다음 편 예고

다음 편 046. Linux 서버 보안 — 설정 변경 이벤트의 SIEM·ELK 연계 에서는 설정 변경 이벤트를 SIEM·ELK로 모아 검색·시각화하는 방법을 다룹니다.


이전 편: 044. Linux 서버 보안 — 자체 점검 스크립트 설계와 결과 표준화
📚 시리즈 전체 보기: 시스템 보안 · 취약점

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

0개의 댓글