047. Linux 서버 보안 — 서버 설정 탐지 규칙 모음(Wazuh 커스텀 룰)

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

선행 학습

• 046. 설정 변경 이벤트의 SIEM·ELK 연계
• 037. 설정 드리프트(Drift)와 취약 설정 탐지

1. 개념

001~046편에서 룰을 편마다 하나씩 만들었습니다. 룰이 흩어져 있으면 ID 충돌, 레벨 불일치, 그룹 누락으로 상관 룰이 동작하지 않는 문제가 생깁니다. 이 편은 룰을 운영 가능한 "룰셋"으로 정리합니다.

룰셋 설계 4요소
① ID 대역   : 시리즈 영역별로 구간을 나눠 충돌 방지 (커스텀 룰은 100000번대 이상 사용)
② 그룹      : 상관 분석 단위 (hardening_drift, account, sudo, ssh_access, audit_tamper ...)
③ 레벨      : 우선순위 기준을 문서화 (아래 표)
④ 검증      : wazuh-logtest 로 예시 로그 매칭 확인 → 배포 → Alert 확인

레벨	이 시리즈의 사용 기준
5~6	정찰·단건 실패 등 참고 이벤트
8~9	설정 변경, 확인이 필요한 정책 이벤트
10~11	정책 위반·보안 장치 약화
12	백도어성 변경(UID 0, 감사 무력화, 핵심 바이너리 변조)
13 이상	여러 이벤트가 결합된 상관 룰

2. 왜 중요한가

• 그룹이 일관돼야 if_matched_group, SIEM의 rule.groups 검색, 대시보드가 모두 동작합니다.
• 레벨 기준이 없으면 관제 인원마다 우선순위 판단이 달라집니다.
• 룰은 코드처럼 버전 관리와 테스트가 필요합니다. 검증 없이 배포한 정규식 하나가 Alert 누락이나 폭증을 만듭니다.

3. 핵심 명령어 / 설정

A영역 룰 요약(ID 대역 100100~100999)입니다.

ID	탐지 내용	권장 그룹(재정리)	레벨	편
100100	/etc/passwd 변경	hardening, account	10	001
100110 / 100111	UID 0 생성 / 서비스 계정 셸 부여	account	12 / 10	003
100130	서비스 계정 sudo root 실행	sudo	12	006
100140	sudo 경유 root 셸 진입	sudo	9	007
100150 / 100160	root SSH 성공 / 키 전용 서버 password 성공	ssh_access	12 / 10	008·009
100180 / 100181	접근 제어 거부 / 서비스 계정 SSH 성공	ssh_access	6 / 11	011
100190	MaxStartups 초과	ssh_access	10	012
100200 / 100330	systemd 유닛 생성 / drop-in 변경	hardening_drift	9 / 11	013·027
100230	firewalld 외 방화벽 규칙 변경	hardening_drift	10	016
100240 / 100241	SELinux 해제 / 웹 프로세스 셸 실행 AVC	hardening_drift	12 / 10	017
100260 / 100270	임시 경로 실행 / /dev/shm 실행	exec_tmp	10 / 12	019·020
100280 / 100290	커널 보안 sysctl 하향 / IP 포워딩	hardening_drift	11 / 12	022·023
100340 / 100350	journal 삭제 / rsyslog 설정 변경	log_tamper	12 / 11	028·029
100370 / 100371	감사 규칙 삭제 / auditd 종료	audit_tamper	12	031
100410 / 100420	core_pattern 변경 / 커널 모듈 로드	hardening_drift	12	035·036
100430	10분 내 하드닝 해제 3건 이상(상관)	hardening_drift	13	037
100440	보안 서비스 중지	hardening_drift	11	039
100490 / 100500	자체 점검 FAIL / SCA 실패 전환	hardening_check, sca	9 / 10	044·045

각 편에서 예시로 붙였던 그룹명은 위 권장 그룹으로 통일해 배포합니다. 다음 영역(B 계정·인증)부터는 101000번대처럼 영역별 1,000개 단위 대역을 사용합니다.

4. 실습 (실습 예시)

# 1) 룰 파일 분리 (관리 서버)
ls /var/ossec/etc/rules/
# local_rules.xml  syssec_a_hardening.xml  syssec_a_audit.xml ...

# 2) 문법·매칭 검증: 예시 로그를 넣어 어떤 룰이 걸리는지 확인
sudo /var/ossec/bin/wazuh-logtest
# 입력 예: Oct  1 03:41:22 rocky9-web01 sshd[5120]: Accepted password for root from 192.168.56.50 port 50122 ssh2
# 출력에서 Phase 3: id '100150', level '12' 확인

# 3) 적용
sudo systemctl restart wazuh-manager
sudo tail -n 20 /var/ossec/logs/ossec.log | grep -iE 'error|warning'

# 4) 룰 파일 버전 관리
cd /var/ossec/etc/rules && sudo git init 2>/dev/null; sudo git add . && sudo git commit -m "A영역 룰셋 v1"

5. 정상 상태

**Phase 3: Completed filtering (rules).
	id: '100150'
	level: '12'
	description: 'SSH root 직접 로그인 성공 (정책 위반)'
	groups: '['local', 'root']'
	firing: 'True'

예시 로그마다 의도한 룰 ID·레벨이 출력되고, 재시작 후 ossec.log에 룰 파싱 오류가 없는 상태가 정상입니다.

6. 이상 상태

$ sudo tail /var/ossec/logs/ossec.log
2026/10/01 06:00:01 wazuh-analysisd: ERROR: Signature ID '100200' is duplicated.
2026/10/01 06:00:01 wazuh-analysisd: CRITICAL: (1220): Error loading the rules: 'etc/rules/syssec_a_hardening.xml'.

• 룰 ID 중복으로 룰 파일 로딩 실패 → 관리 서버 분석 엔진이 시작되지 않을 수 있음
• 운영 중 이런 오류는 탐지 공백으로 직결되므로, 배포 전 wazuh-logtest·테스트 서버 검증이 필수입니다.

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

룰셋 품질은 "얼마나 많이 울리는가"로 점검합니다(분석 방법 예시 — 최근 7일 룰별 Alert 건수).

rule.id   description                                  7일 건수   판단
100200    신규 systemd 유닛/링크 생성                   412       과다 → 패키지 업데이트 시 대량 발생, 조건 보완 필요
100140    sudo 경유 root 셸 진입                        96        관리자 업무 패턴 확인 → 업무 외 시간 조건 추가 검토
100150    SSH root 직접 로그인 성공                     0         정상(정책 준수)
100430    하드닝 해제 상관                              1         10/01 rocky9-web01 → 정탐(사고 처리)

0건 룰은 "탐지 대상이 없음"일 수도, "룰이 동작하지 않음"일 수도 있습니다. 주기적으로 예시 로그 재주입 테스트로 동작을 확인합니다.

8. SOC 관제 포인트

• 신규 룰은 예시 로그(정탐 1개 + 오탐 후보 1개 이상)로 검증한 뒤 배포합니다.
• 룰별 Alert 건수를 주간 점검해 과다(튜닝)·0건(동작 확인) 룰을 관리합니다.
• 상관 룰이 참조하는 그룹(hardening_drift 등)이 개별 룰에 빠짐없이 붙어 있는지 확인합니다.

9. 탐지 규칙

룰 파일 하나의 구성 예시입니다(그룹·레벨 체계를 반영).

<!-- /var/ossec/etc/rules/syssec_a_hardening.xml -->
<group name="local,syssec_a,hardening_drift,">
  <rule id="100240" level="12">
    <if_group>audit</if_group>
    <match>type=MAC_STATUS</match>
    <regex>enforcing=0 old_enforcing=1</regex>
    <description>SELinux Enforcing 해제(setenforce 0)</description>
    <mitre><id>T1562.001</id></mitre>
  </rule>
  <rule id="100430" level="13" frequency="3" timeframe="600">
    <if_matched_group>hardening_drift</if_matched_group>
    <same_location />
    <description>짧은 시간 내 다수 하드닝 설정 완화</description>
  </rule>
</group>

<mitre> 태그로 MITRE ATT&CK 기법 ID(T1562.001: 보안 도구 비활성화·수정)를 붙이면 Wazuh 대시보드의 MITRE 화면에서 기법별로 Alert를 볼 수 있습니다.

10. 대응 방법

1. 초기 확인 — 룰 로딩 오류·과다·0건 룰을 확인합니다.
2. 범위 확인 — 문제 룰이 영향을 준 기간(탐지 공백·Alert 폭증)을 파악합니다.
3. 증거 확보 — 룰 파일 변경 이력(git)과 오류 로그를 보존합니다.
4. 차단/조치 — 룰을 수정·롤백하고 wazuh-logtest로 재검증 후 배포합니다.
5. 재발 방지 — ID 대역·그룹·레벨 기준을 문서화하고 주간 룰 품질 점검을 운영합니다.

11. 핵심 정리

구분	핵심 내용
ID 대역	영역별 1,000 단위 (A: 100100~100999, B: 101000~)
그룹	상관 분석 단위 — 개별 룰에 빠짐없이 부여
레벨 기준	5~6 참고 · 8~9 변경 · 10~11 위반 · 12 백도어성 · 13+ 상관
검증	wazuh-logtest → 테스트 → 배포 → 건수 점검
면접 포인트	"0건 룰은 정상일 수도, 고장일 수도 — 재주입 테스트로 확인"

12. 다음 편 예고

다음 편 048. Linux 서버 보안 — 설정 변경 Alert 정탐·오탐 판단 에서는 룰이 울린 뒤 가장 중요한 판단인 설정 변경 Alert의 정탐·오탐 판단을 다룹니다.

---

이전 편: 046. Linux 서버 보안 — 설정 변경 이벤트의 SIEM·ELK 연계
📚 시리즈 전체 보기: 시스템 보안 · 취약점